Population-based medication stewardship

ABSTRACT

Methods, systems, computer storage media, and graphical user interfaces for population health management are disclosed. The population health management system may allow for cross-continuum tracking and subsequent interactions with transactional systems, providers, and/or patients. The population health management system may include utilizing clinically relevant algorithms to populate registries to enable healthcare providers to better facilitate care for a population of patients. The population health management system may consolidate and provide comprehensive condition-specific and/or patient situation specific information that is accessible and updatable across venues. The population health management system may create cross venue antibiograms based on medications information and susceptibility results which can be filtered for selected demographics. The population health management system may be utilized to provide multiple medication options including dosing, generic alternatives, cost, availability, and susceptibility information. Inappropriate trends may be flagged and monitored and medication stewards may be alerted or notified to intervene.

CROSS-REFERENCE TO RELATED APPLICATIONS

This Application is a continuation of U.S. patent application Ser. No.14/502,316, filed Sep. 30, 2014, which claims priority to U.S.Provisional Application Ser. No. 61/885,359, filed Oct. 1, 2013, andU.S. Provisional Application Ser. No. 61/888,313, filed Oct. 8, 2013,herein incorporated by reference in their entireties, and is related tocommonly assigned U.S. patent applications entitled “ComprehensiveMedication Advisor” (Attorney Docket CRNI.213287), “Population HealthCondition Worklist” (Attorney Docket CRNI.208052), “Population HealthCare Transition” (Attorney Docket CRNI.208054), “Population HealthCondition Management” (Attorney Docket CRNI.208055), and “PopulationHealth Situational Awareness” (Attorney Docket CRNI.208056), filedconcurrently herewith on the same date.

BRIEF SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Embodiments of the present invention generally relate to designing andutilizing population health programs to allow for cross-continuumtracking and subsequent interactions with transactional systems,providers, patients, etc. Clinically relevant algorithms may be utilizedto populate registries, which can enable healthcare providers to betterfacilitate care for a population of patients. Comprehensivecondition-specific and/or patient situation specific information may beconsolidated and provided that is accessible and updatable by multipleproviders and venues. Cross venue care related information (e.g.,antibiograms based on culture, medications information, and/orsusceptibility results) may be created which can be filtered forselected demographics. Multiple medication and/or treatment optionsincluding dosing, generic alternatives, cost, availability, andsusceptibility information may be provided and inappropriate trends maybe flagged and monitored so medication stewards can be alerted ornotified to intervene.

Accordingly, in one aspect, an embodiment of the present invention isdirected to one or more computer storage media storingcomputer-executable instructions that, when executed by one or morecomputing devices, cause the one or more computing devices to perform amethod that facilitates designing and utilizing population healthprograms. The method includes receiving, at a population health server,healthcare data from disparate sources. The method further includesutilizing the population health server to identify a population ofpatients based on a set of criteria. The method also includes utilizingthe population health server to stratify the population of patientsbased on one or more algorithms to create one or more groups ofpatients. At least one group of the one or more groups of patientscomprises a plurality of patients having at least one substantiallysimilar attribute. The method further includes utilizing the populationhealth server to create at least one registry, the at least one registrycomprising at least a portion of the one or more groups.

A further embodiment is directed to a system that includes one or moreprocessors; and a non-transitory computer storage medium storingcomputer-useable instructions that, when used by the one or moreprocessors, cause the one or more processors to: receive healthcare datafrom disparate sources; identify a population of patients based on a setof criteria; stratify the population of patients based on one or morealgorithms; and create a registry for at least a portion of thepopulation of patients, wherein the registry accounts for one or moreof: resources available to a patient; lifestyle and prognostic assetsthat can be used for prediction; and assets necessary for attribution,allocation, or measurement.

In another embodiment of the invention, an aspect is directed to one ormore computer storage media storing computer-executable instructionsthat, when executed by one or more computing devices, cause the one ormore computing devices to perform a method that facilitates designingand utilizing population health programs. The method includes receiving,at a population health server, healthcare data from disparate sources.The healthcare data may comprise one or more of clinical data,healthcare-related financial data, and patient sensor and/or patientdevice data. The method further includes utilizing the population healthserver to identify a population of patients based on one or more medicalconditions. The method also includes utilizing the population healthserver to stratify the population of patients into one or more groupsbased on at least one algorithm. Each group of the one or more groupsmay comprise one or more patients having a substantially similar medicalcondition. The method further includes providing an opportunity for aclinician to confirm an output of the at least one algorithm. The methodalso includes utilizing the population health server to create at leastone registry for the population of patients based on at least a portionof the output of the at least one algorithm.

In another aspect, an embodiment of the present invention is directed toone or more computer storage media storing computer-executableinstructions that, when executed by one or more computing devices, causethe one or more computing devices to perform a method for providing across venue antibiogram. The method comprises receiving medicationsinformation from disparate sources including information from multiplevenues, multiple providers, and across multiple conditions. The methodfurther comprises receiving susceptibility results based on testingassociated with patient information from the disparate sources. Themethod also comprises creating a cross venue antibiogram based on themedications information and the susceptibility results. The methodfurther comprises communicating the cross venue antibiogram to aclinician device.

In another embodiment of the invention, an aspect is directed to acomputer-implemented method. The method includes receiving, from aclinician device, a selection of a disease state for a patient. Themethod further includes receiving patient information, from anElectronic Medical Record (EMR). The patient information includesrelated conditions, laboratory results, and allergy information for thepatient. The method also includes utilizing susceptibility data, basedon a cross venue antibiogram, to provide one or more medication optionsfor the disease state. The antibiogram is based on medicationsinformation from disparate sources including multiple venues, multipleproviders, and across multiple conditions. The method further includesproviding the one or more medication options to the clinician device.The one or more medication options includes one or more of dosing,generic alternatives, cost, and availability.

A further embodiment is directed to a system that includes one or moreprocessors; and a non-transitory computer storage medium storingcomputer-useable instructions that, when used by the one or moreprocessors, cause the one or more processors to: receive medicationsinformation from disparate data sources, the data sources includingmultiple venues, multiple providers, and across multiple conditions;receive susceptibility results based on testing associated with patientinformation provided by the disparate sources; create a cross venueantibiogram based on the medications information and the susceptibilityresults; provide the cross venue antibiogram to a device associated witha clinician; and enable filtering of the cross venue antibiogram basedon selected demographics, the selected demographics including aninstitution, a practice associated with a clinician, a zip code, acounty, a city, a state, a region, or a country.

In another aspect, an embodiment of the present invention is directed toone or more computer storage media storing computer-executableinstructions that, when executed by one or more computing devices, causethe one or more computing devices to perform a method for stratifyingone or more patients into one or more groups. The method includesreceiving, at a population health server, healthcare data, where thehealthcare data includes clinical impressions and/or clinical narrativesfrom one or more healthcare providers. The method further includesutilizing the population health server for natural language processingto extract one or more clinical indicators from the healthcare data. Inaddition, the method includes utilizing the population health server tostratify one or more patients into one or more groups based on at leasta portion of the one or more clinical indicators. Furthermore, themethod includes utilizing the population health server to create atleast one registry including the one or more groups. The at least oneregistry accounts for one or more of: resources available to a patient;lifestyle and prognostic assets that can be used for prediction; andassets necessary for attribution, allocation, or measurement.

In another aspect, a further embodiment is directed to a computer systemthat stratifies one or more patients into one or more groups, thecomputer system including a processor coupled to a computer storagemedium, the computer storage medium having stored thereon a plurality ofcomputer software components executable by the processor. The computersoftware components include a receiving component that receiveshealthcare data, where the healthcare data includes clinical impressionsand/or clinical narratives from one or more healthcare providers. Thecomputer software components further include a natural languageprocessing component that extracts one or more clinical indicators fromthe healthcare data, and a stratifying component that utilizes one ormore algorithms to stratify one or more patients into one or more groupsbased on at least a portion of the one or more clinical indicators. Inaddition, the computer software components include a creating componentthat creates at least on registry. The at least one registry includes atleast a portion of the one or more groups, where the at least oneregistry accounts for one or more of: resources available to a patient;lifestyle and prognostic assets that can be used for prediction; andassets necessary for attribution, allocation, or measurement.

In another aspect, an embodiment of the present invention is directed toone or more computer storage media storing computer-executableinstructions that, when executed by one or more computing devices, causethe one or more computing devices to perform a method for stratifyingone or more patients into one or more groups. The method includesreceiving, at a population health server, healthcare data from disparatesources, where the healthcare data includes clinical impressions and/orclinical narratives from one or more healthcare providers. The methodfurther includes utilizing the population health server for naturallanguage processing to extract one or more clinical indicators from thehealthcare data, where the one or more clinical indicators areassociated with one or more chronic conditions. In addition, the methodincludes providing a relevance rating to each of the one or moreclinical indicators, and utilizing the population health server tostratify one or more patients into one or more groups based on at leasta portion of the one or more clinical indicators. Further, the methodincludes utilizing the population health server to create at least oneregistry including the one or more groups, where the at least oneregistry accounts for one or more of: resources available to a patient;lifestyle and prognostic assets that can be used for prediction; andassets necessary for attribution, allocation, or measurement.

In another aspect, an embodiment of the present invention is directed toone or more computer storage media storing computer-executableinstructions that, when executed by one or more computing devices, causethe one or more computing devices to perform a method that facilitatesusing at least one clinically relevant algorithm in population healthprograms. The method includes receiving, at a population health server,healthcare data from disparate sources. The method further includesutilizing the population health server to stratify a population ofpatients based on one or more algorithms to create one or more groups ofpatients, where at least one group of the one or more groups of patientscomprises a plurality of patients having at least one substantiallysimilar attribute. The one or more algorithms include at least oneclinically relevant algorithm utilizing clinical data. In addition, themethod includes utilizing the population health server to create atleast one registry, the at least one registry including at least aportion of the one or more groups.

In another aspect, a further embodiment is directed to a computer systemthat facilitates designing and utilizing population health programs, thecomputer system including a processor coupled to a computer storagemedium, the computer storage medium having stored thereon a plurality ofcomputer software components executable by the processor. The computersoftware components include a receiving component that receiveshealthcare data from disparate sources, and a stratifying component thatstratifies a population of patients based on one or more algorithms. Theone or more algorithms comprising at least one clinically relevantalgorithm. The computer software components further include a creatingcomponent that creates a registry for at least a portion of thepopulation of patients. The registry accounts for one or more of:resources available to a patient; lifestyle and prognostic assets thatcan be used for prediction; or assets necessary for attribution,allocation, or measurement.

In another aspect, an embodiment of the present invention is directed toone or more computer storage media storing computer-executableinstructions that, when executed by one or more computing devices, causethe one or more computing devices to perform a method that facilitatesutilizing clinically relevant algorithms for registry population. Themethod includes receiving, at a population health server, healthcaredata from disparate sources, and utilizing the population health serverto identify a population of patients based, at least partly, on one ormore medical conditions. The method further includes utilizing thepopulation health server to stratify the population of patients based onat least a clinically relevant algorithm. The clinically relevantalgorithm utilizes clinical data, and the clinical data includes one ormore of medication information, laboratory values, diagnostics,clinician narratives, and clinician assessments. In addition, the methodincludes utilizing the population health server to create at least oneregistry for the population of patients based on at least a portion ofan output of the clinically relevant algorithm. The method furtherincludes utilizing the population health server to update the at leastone registry when additional clinical data is available for theclinically relevant algorithm to utilize.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are described in detail below with reference to the attacheddrawing figures, wherein:

FIG. 1 is a block diagram of an exemplary computing environment suitableto implement embodiments of the present invention;

FIG. 2 is a block diagram of an exemplary population health managementsystem to implement embodiments of the present invention;

FIG. 3 is a flow diagram illustrating exemplary methods of utilizing anidentification algorithm for registry population, in accordance withembodiments of the present invention;

FIG. 4 is a flow diagram illustrating exemplary methods of utilizing astratification algorithm for stratification one or more patients in aregistry, in accordance with embodiments of the present invention;

FIG. 5 is a flow diagram illustrating exemplary methods for utilizing analgorithm to provide transition management care, in accordance withembodiments of the present invention;

FIG. 6 is a flow diagram illustrating exemplary methods for utilizing analgorithm to provide transition management care, in accordance withembodiments of the present invention;

FIG. 7 is a flow diagram illustrating exemplary methods for utilizing analgorithm to provide transition management care, in accordance withembodiments of the present invention;

FIG. 8 is a flow diagram illustrating exemplary methods for utilizing analgorithm to provide transition management care, in accordance withembodiments of the present invention;

FIG. 9 is a flow diagram illustrating exemplary methods of utilizing anidentification algorithm for registry population, in accordance withembodiments of the present invention;

FIG. 10 is a flow diagram illustrating exemplary methods of utilizing astratification algorithm for stratification one or more patients in aregistry, in accordance with embodiments of the present invention;

FIG. 11 is a flow diagram illustrating exemplary methods for utilizingan algorithm to provide transition management care, in accordance withembodiments of the present invention;

FIG. 12 is a flow diagram illustrating exemplary methods for utilizingan algorithm for assigning a physician to one or more patient in a heartfailure registry, in accordance with embodiments of the presentinvention;

FIG. 13 is a flow diagram illustrating exemplary methods for utilizingan algorithm to provide transition management care, in accordance withembodiments of the present invention;

FIGS. 14-27 depict illustrative screen displays, in accordance withexemplary embodiments of the present invention;

FIG. 28 is a flow diagram illustrating an exemplary method thatfacilitates designing and utilizing population health programs, inaccordance with embodiments of the present invention;

FIG. 29 is a flow diagram illustrating an exemplary method thatfacilitates designing and utilizing population health programs, inaccordance with embodiments of the present invention;

FIG. 30 is a flow diagram illustrating an exemplary method forstratifying one or more patients into one or more groups, in accordancewith embodiments of the present invention;

FIG. 31 is a flow diagram illustrating an exemplary method forstratifying one or more patients into one or more groups, in accordancewith embodiments of the present invention;

FIG. 32 is a flow diagram illustrating an exemplary method forfacilitating the use of at least one clinically relevant algorithm inpopulation health programs, in accordance with embodiments of thepresent invention;

FIG. 33 is a flow diagram illustrating an exemplary method forfacilitating the use of clinically relevant algorithms for registrypopulation, in accordance with embodiments of the present invention;

FIG. 34 is a flow diagram illustrating an exemplary method for providinga cross venue antibiogram, in accordance with embodiments of the presentinvention; and

FIG. 35 is a flow diagram illustrating an exemplary method for providinga comprehensive medication advisor, in accordance with embodiments ofthe present invention;

DETAILED DESCRIPTION

The subject matter of the present invention is described withspecificity herein to meet statutory requirements. However, thedescription itself is not intended to limit the scope of this patent.Rather, the inventors have contemplated that the claimed subject mattermight also be embodied in other ways, to include different steps orcombinations of steps similar to the ones described in this document, inconjunction with other present or future technologies. Moreover,although the terms “step” and/or “block” may be used herein to connotedifferent elements of methods employed, the terms should not beinterpreted as implying any particular order among or between varioussteps herein disclosed unless and except when the order of individualsteps is explicitly described.

Currently there is not a comprehensive and convenient healthcaremanagement system and/or method for a user, e.g., a healthcare provider,to understand populations of patients within their own transactionalsystem, much less across a community or geographic area. Further,current population healthcare management systems are limited in thatsuch systems do not effectively utilize various types of data associatedwith a population of patients, nor do such systems provide effectiveconsistency across all venues and conditions.

Accordingly, various aspects of the technology described herein aregenerally directed to methods, systems, computer storage media, andgraphical user interfaces for population health management. Variousembodiments of the present invention are directed to facilitating thedesign and utilization of a population health management system to allowfor cross-continuum tracking and subsequent interactions withtransactional systems, providers, patients, etc. In embodiments, thepopulation health management system can include utilizing clinicallyrelevant algorithms to populate registries, which can enable healthcareproviders to better facilitate care for a population of patients. Incertain embodiments, the population health management system canconsolidate and provide comprehensive condition-specific and/or patientsituation specific information that is accessible and updatable bymultiple providers and venues. In embodiments, the population healthmanagement system can create cross venue antibiograms based onmedications information and susceptibility results which can be filteredfor selected demographics. In embodiments, the population healthmanagement system can be utilized to provide multiple medication optionsincluding dosing, generic alternatives, cost, availability, andsusceptibility information. In embodiments, inappropriate trends may beflagged and monitored and medication stewards may be alerted or notifiedto intervene.

An exemplary computing environment suitable for use in implementingembodiments of the present invention is described below. FIG. 1 is anexemplary computing environment (e.g., medical-informationcomputing-system environment) with which embodiments of the presentinvention may be implemented. The computing environment is illustratedand designated generally as reference numeral 100. The computingenvironment 100 is merely an example of one suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the invention. Neither should thecomputing environment 100 be interpreted as having any dependency orrequirement relating to any single component or combination ofcomponents illustrated therein.

The present invention might be operational with numerous other purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that might besuitable for use with the present invention include personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of theabove-mentioned systems or devices, and the like.

The present invention might be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Exemplary program modules comprise routines,programs, objects, components, and data structures that performparticular tasks or implement particular abstract data types. Thepresent invention might be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules might be located in association with localand/or remote computer storage media (e.g., memory storage devices).

With continued reference to FIG. 1, the computing environment 100comprises a computing device in the form of a control server 102.Exemplary components of the control server 102 comprise a processingunit, internal system memory, and a suitable system bus for couplingvarious system components, including data store 104, with the controlserver 102. The system bus might be any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, and a local bus, using any of a variety of bus architectures.Exemplary architectures comprise Industry Standard Architecture (ISA)bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus,Video Electronic Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus, also known as Mezzanine bus.

The control server 102 typically includes therein, or has access to, avariety of computer-readable media. Computer-readable media can be anyavailable media that might be accessed by control server 102, andincludes volatile and nonvolatile media, as well as, removable andnonremovable media. By way of example, and not limitation,computer-readable media may comprise computer storage media andcommunication media. Computer storage media includes both volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canbe accessed by control server 102. Communication media typicallyembodies computer-readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer-readable media.

The control server 102 might operate in a computer network 106 usinglogical connections to one or more remote computers 108. Remotecomputers 108 might be located at a variety of locations in a medical orresearch environment, including clinical laboratories (e.g., moleculardiagnostic laboratories), hospitals and other inpatient settings,veterinary environments, ambulatory settings, medical billing andfinancial offices, hospital administration settings, home healthcareenvironments, and clinicians' offices. Clinicians or healthcareproviders may comprise a treating physician or physicians; specialistssuch as surgeons, radiologists, cardiologists, and oncologists;emergency medical technicians; physicians' assistants; nursepractitioners; health coaches; nurses; nurses' aides; pharmacists;dieticians; microbiologists; laboratory experts; laboratorytechnologists; genetic counselors; researchers; veterinarians; students;and the like. The remote computers 108 might also be physically locatedin nontraditional medical care environments so that the entirehealthcare community might be capable of integration on the network. Theremote computers 108 might be personal computers, servers, routers,network PCs, peer devices, other common network nodes, or the like andmight comprise some or all of the elements described above in relationto the control server 102. The devices can be personal digitalassistants or other like devices.

Computer networks 106 comprise local area networks (LANs) and/or widearea networks (WANs). Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets, and the Internet.When utilized in a WAN networking environment, the control server 102might comprise a modem or other means for establishing communicationsover the WAN, such as the Internet. In a networking environment, programmodules or portions thereof might be stored in association with thecontrol server 102, the data store 104, or any of the remote computers108. For example, various application programs may reside on the memoryassociated with any one or more of the remote computers 108. It will beappreciated by those of ordinary skill in the art that the networkconnections shown are exemplary and other means of establishing acommunications link between the computers (e.g., control server 102 andremote computers 108) might be utilized.

In operation, an organization might enter commands and information intothe control server 102 or convey the commands and information to thecontrol server 102 via one or more of the remote computers 108 throughinput devices, such as a keyboard, a pointing device (commonly referredto as a mouse), a trackball, or a touch pad. Other input devicescomprise microphones, satellite dishes, scanners, or the like. Commandsand information might also be sent directly from a remote healthcaredevice to the control server 102. In addition to a monitor, the controlserver 102 and/or remote computers 108 might comprise other peripheraloutput devices, such as speakers and a printer.

Although many other internal components of the control server 102 andthe remote computers 108 are not shown, such components and theirinterconnection are well known. Accordingly, additional detailsconcerning the internal construction of the control server 102 and theremote computers 108 are not further disclosed herein.

Turning now to FIG. 2, an exemplary population health management system200 suitable for use in implementing embodiments of the presentinvention is depicted. The population health management system 200 ismerely an example of one suitable computing system environment and isnot intended to suggest any limitation as to the scope of use orfunctionality of embodiments of the present invention. Neither shouldthe population health management system 200 be interpreted as having anydependency or requirement related to any single module/service/componentor combination of modules/services/components illustrated therein.

The population health management system 200 may include a populationhealth server 250, electronic medical records 212 (EMRs), activity data214 patient and/or population demographic information 216, consumerprofile information 218, provider information 220, one or more outputregistry databases 230, and/or one or more computing devices 240, all incommunication with each other through wired or wireless connectionsand/or through the network 210. The network 210 may include, withoutlimitation, one or more local area networks (LANs) and/or wide areanetworks (WANs). Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets and the Internet.Accordingly, the network is not further described herein.

In embodiments, the EMRs 212 may span multiple applications, multipleproviders, multiple patients, multiple conditions, multiple venues,multiple facilities, multiple organizations, and/or multiplecommunities. Embodiments of the EMRs 212 may include one or more datastores of healthcare records, which may include one or more computers orservers that facilitate the storing and retrieval of the healthcarerecords. In some embodiments, one or more EMRs 212 may be implemented asa cloud-based platform or may be distributed across multiple physicallocations. Example embodiments of the EMRs 212 may include hospital,ambulatory, clinic, health exchange, and health plan records systems.The EMRs 212 may further include record systems, which store real-timeor near real-time patient (or user) information, such as wearable,bedside, or in-home patient monitors, for example. It is furthercontemplated that embodiments of the EMRs 212 may use distinct clinicalontologies, nomenclatures, vocabularies, or encoding schemes forclinical information, or clinical terms. Further, in some embodiments,the EMRs 212 may be affiliated with two or more separate health careentities and/or venues that use two or more distinct nomenclatures.

In embodiments, the EMRs 212 described herein may include healthcaredata. As used herein, healthcare data refers to any healthcare ormedical care data related or relevant to a patient. Healthcare data mayinclude, but is not limited to, clinical data and healthcare-relatedfinancial data. Clinical data, as used herein, refers to any healthcareor medical data particular to a patient. In embodiments, clinical datacan be medical care or healthcare data resulting from or associated witha health or medical service performed in association with a clinician ina healthcare environment (e.g., lab test, diagnostic test, clinicalencounter, ecare, evisit, etc.). Clinical data may include, but is notlimited to, a health history of a patient, a diagnosis, a clinicianassessment, clinician narrative, a treatment, a family history(including family health history and/or family genetics), animmunization record, a medication, age, gender, date of birth,laboratory values, diagnostics, a test result, an allergy, a reaction, aprocedure performed, a social history, an advanced directive, frequencyand/or history of healthcare facility visits, current healthcareproviders and/or current healthcare provider location, preferredpharmacy, prescription benefit management data, an alert, claims data, avital, data traditionally captured at the point of care or during thecare process, a combination thereof, and the like. In the same oralternative embodiments, the clinical data may include medicalcompliance information. In certain embodiments, medical complianceinformation refers to a level of compliance of a particular patient withone or more prescribed medical treatments, such as medications, diet,physical therapy, follow up healthcare visits, and the like. In one ormore embodiments, the clinical data may include data obtained from thenatural language processing of one or more clinical assessments and/orclinical narratives.

In certain embodiments, healthcare-related financial data can refer toany financial information relevant to a patient, such as insurance data,claims data, payer data, etc. Such healthcare data (e.g., clinical dataand healthcare-related financial data) may be submitted by a patient, acare provider, a payer, etc. In certain embodiments where the healthcaredata is being submitted by anyone other than the patient, the patientmay be required to approve of such submission and/or may opt-in to oropt-out of having such healthcare data being submitted.

In embodiments, activity data 214 can refer to health actions oractivities performed by a patient outside of, or remote from, ahealthcare environment. Embodiments of activity data 214 may include oneor more data stores of activity data 214, which may include one or morecomputers or servers that facilitate the storing and retrieval of theactivity data 214. In some embodiments, the activity data 214 may beimplemented as a cloud-based platform or may be distributed acrossmultiple physical locations. Example embodiments of the activity data214 may include nutrition information and/or exercise information for apatient. In certain embodiments, at least a portion of the activity data214 may be recorded utilizing a personal fitness tracker, a smart phone,and/or an application provided by a smart phone. In various embodiments,the activity data 214 may include data obtained from a patient's car.For example, in such embodiments, the activity data 214 may include dataon the amount of driving the patient does versus the amount of walkingthe patient does.

In one or more embodiments, the activity data 214 may be submitted by apatient, a third party associated with a personal fitness tracker and/orsmart phone (such as a software developer or device manufacturer), acare provider, a payer, etc. In certain embodiments where the activity214 is being submitted by anyone other than the patient, the patient maybe required to approve of such submission and/or may opt-in to oropt-out of having such healthcare data being submitted.

The patient and/or population demographic information 216 may includeage, gender, date of birth, address, phone number, contact preferences,primary spoken language, technology access (e.g., internet, phone,computer, etc.), transportation (e.g., common modes of transportation),education level, motivation level, work status (student, full-time,retired, unemployed, etc.), and/or income. In certain embodiments, thepatient and/or population demographic information 216 may includecommunity resource information, which may include, but is not limitedto, fitness facility information, pharmacy information, food bankinformation, grocery store information, public assistance programs,homeless shelters, etc. In embodiments, the motivation level can includethe level of motivation a particular patient has for maintaining theirhealth, which may be derived from other information (e.g., data frompersonal fitness tracker, indication the patient regularly visits aclinician for check-ups, consumer profile information, etc.).Embodiments of the patient and/or population demographic information 216may include one or more data stores of demographic information 216 whichmay include one or more computers or servers that facilitate the storingand retrieval of the demographic information 216. In some embodiments,the patient and/or population demographic information 216 may beimplemented as a cloud-based platform or may be distributed acrossmultiple physical locations. In embodiments, the patient and/orpopulation demographics 216 may be obtained through any source known toone skilled in the art. For example, in certain embodiments, at least aportion of the patient and/or population demographic information 216 maybe submitted by a third party that relies on census data. In variousembodiments, the patient and/or population demographic information 216may be obtained from more than one source. In one embodiment, thepatient may submit any or all of the patient and/or populationdemographic information 216. In certain embodiments, all or a portion ofthe patient and/or population demographic information 216 may beanonymized using techniques known to one skilled in the art.

In one or more embodiments, the consumer profile information 218 mayinclude any or all of the spending habits of one or more patients withina population. For instance, in certain embodiments, the consumer profileinformation 218 may include information associated with grocery storepurchases, athletic or exercise equipment purchases, restaurantpurchases, and/or purchases of vitamins and/or supplements. Embodimentsof the consumer profile information 218 may include one or more datastores of consumer profile information 218 which may include one or morecomputers or servers that facilitate the storing and retrieval of theconsumer profile information 218. In some embodiments, the consumerprofile information 218 may be implemented as a cloud-based platform ormay be distributed across multiple physical locations. In oneembodiment, a patient may provide the consumer profile information 218,for example, by linking checking account and/or checking accountpurchase information to at least a portion of the population healthmanagement system 200 and/or to a health insurance carrier.

The care provider information 220 may include any information relatingto a particular care provider or healthcare facility. In one embodiment,the care provider information 220 may include information relating tothe number of healthcare providers and their specialties at a particularcare provider location. In the same or alternative embodiments, the careprovider information 220 may include information relating tonon-personnel type resources at a particular care provider location,such as the amount and types of medications and/or the amount and typesof surgical or other medical equipment. In one embodiment, the careprovider information 220 may include one or more of address and contactinformation, accepted payer information, status on accepting newpatients, transactional systems, primary spoken language, hospitalaffiliations, and/or care delivery models. In embodiments, the careprovider information 220 may include information relating to theavailability of any or all resources at a particular healthcare facilityincluding personnel and/or non-personnel resources. Embodiments of thecare provider information 220 may include one or more data stores ofcare provider information 220 which may include one or more computers orservers that facilitate the storing and retrieval of the care providerinformation 220. In some embodiments, the care provider information 220may be implemented as a cloud-based platform or may be distributedacross multiple physical locations. In one embodiment, the care providerinformation 220 can be provided by a healthcare provider, and/or a thirdparty, such as an insurance provider or management entity.

In one or more embodiments, the output registry databases 230, which mayinclude the output registries, may be networked storage or distributedstorage including storage on servers located in the cloud. Thus, it iscontemplated that for some embodiments, the information stored in theoutput registry databases 230 is not stored in the same physicallocation. The information within the output registry databases 230 mayexist in a variety of standardized formats including, for example,narratives and other data. Information in the output registry databases230 may be categorized or classified according to, for example, claims,diagnoses, wellness, satisfaction, population directories, and the like.

In various embodiments, each output registry may be used by, forexample, a healthcare organization to manage the health of a populationsegment. In one or more embodiments, each output registry may becondition specific. By way of example, a healthcare organization orclinician may manage diabetic patients within a proscribed geographicarea. The condition in this example is diabetes mellitus and the outputregistry may help the healthcare organization manage a populationsegment with this condition. The output registry may, in one aspect,include identified patients within a population segment who have thiscondition or have risk factors that may lead to the development ofdiabetes, such as those identified by the identifying component 254 ofthe population health server 250. The output registry may furtherinclude stratified patients within an identified segment by degree ofseverity or risk, such as those stratified by the stratifying component256 of the population health server 250. The stratified patients in anoutput registry may facilitate the generation of interventions or actionworkflows designed to reduce disease severity or risk and to improveoutcome. Additional uses for the output registries are to measureoutcomes related to treatment interventions and also to attributepatients within the identified segment to appropriate healthcareproviders (e.g., primary care physicians, care managers health coaches,specialists such as endocrinologists, podiatrists, and the like).

In embodiments, the devices 240 can include a remote computer, such asthe remote computers 108 discussed above with reference to FIG. 1. Inone or more embodiments, the devices 240 can include any or all of theproperties and parameters of the remote computers 108 discussed abovewith reference to FIG. 1. In certain embodiments, any or all portions ofoutput generated by the population health server, e.g., the outputregistries 230, the antibiogram database 235, etc., may be provided toor accessible via one or more of the devices 240.

The population health server 250 depicted in FIG. 2 is merely exemplary.While the population health server 250 is illustrated as a single unit,it will be appreciated that the population health server 250 may includeone or more separate components, services, and/or modules. Further inembodiments, the population health server 250 may be scalable. Forexample, the population health server 250 may in actuality include aplurality of computing devices in communication with one another.Components of the population health server 250 may include a processingunit, internal system memory, and a suitable system bus for couplingvarious system components, including one or more data stores for storinginformation (e.g., files and metadata associated therewith). Inembodiments, each of these components/services/modules typicallyincludes, or has access to, a variety of computer-readable media.

In some embodiments, one or more of the illustrated components of thepopulation health server 250 may be implemented as one or morestand-alone applications. Further, various components, services, and/ormodules may be located on any number of servers. By way of example only,the population health server 250 might reside on a server, cluster ofservers, a cloud-computing device or distributed computing architecture,or a computing device remote from one or more of the remainingcomponents.

It should be understood that this and other arrangements describedherein are set forth only as examples. Other arrangements and elements(e.g., machines, interfaces, functions, orders, and groupings offunctions, etc.) can be used in addition to or instead of those shown,and some elements may be omitted altogether. Further, many of theelements described herein are functional entities that may beimplemented as discrete or distributed components or in conjunction withother components and/or modules, and in any suitable combination andlocation. Various functions described herein as being performed by oneor more entities may be carried out by hardware, firmware, and/orsoftware. For instance, various functions described herein withreference to the population health server 250 may be carried out by aprocessor executing instructions stored in memory.

As discussed above, the population health server 250 may comprise one ormore components, services, and/or modules. For example, as depicted inFIG. 2, the population health server 250 may include a receivingcomponent 252, an identifying component 254, a stratifying component256, a creating component 258, an output component 260, a predictioncomponent 262, a consolidation component 264, a worklist component 266,a situational component 268, a natural language processing component270, an antibiogram component 272, a medication advisor component 274, amedication stewardship component 276, a management component 278, ahealthcare transition component 280, a condition component 282, apatient portal component 284, and a baseline component 286. In certainembodiments, one or more of the components 252, 254, 256, 258, 260, 262,264, 266, 268, 270, 272, 274, 276, 278, 280, 282, 284, and 286 may beconfigured to provide or convey information that can populate agraphical user interface, which may be viewed on a device, such as oneof the devices 240.

In one or more embodiments, one or more of the components 252, 254, 256,258, 260, 262, 264, 266, 268, 270, 272, 274, 276, 278, 280, 282, 284,and 286 may be implemented as stand-alone applications. In otherembodiments, one or more of the components 252, 254, 256, 258, 260, 262,264, 266, 268, 270, 272, 274, 276, 278, 280, 282, 284, and 286 may beintegrated directly into the operating system of a computing device,such as the remote computer 108 of FIG. 1 and/or the one or morecomputing devices 240 of FIG. 2. It will be understood that thecomponents 252, 254, 256, 258, 260, 262, 264, 266, 268, 270, 272, 274,276, 278, 280, 282, 284, and 286 illustrated in FIG. 2 are exemplary innature and in number and should not be construed as limiting. Any numberof components and/or modules may be employed to achieve the desiredfunctionality within the scope of embodiments hereof.

In certain embodiments, the receiving component 252 can receivehealthcare data from disparate sources. In one or more embodiments, thedisparate sources may include one or more EMRs, e.g., the EMRs 212, eachof which may be independent from one another. In certain embodiments,the disparate sources may include a plurality of EMRs, e.g., the EMRs212. In embodiments, the plurality of EMRs may be associated with aplurality of healthcare providers, a plurality of patients, a pluralityof medical conditions, a plurality of healthcare venues and/orfacilities, a plurality of organizations, and/or a plurality ofcommunities. In certain embodiments, at least a portion of the EMR'sreceived by the receiving component 252 may be associated with the samepatient.

In one or more embodiments, in addition to or in place of the healthcaredata, the receiving component 252 can receive one or more of activitydata, e.g., the activity data 214; demographic information, e.g., thepatient and/or population demographic information 216; consumerinformation, e.g., the consumer profile information 218; and providerinformation, e.g., the care provider information 220. In suchembodiments, the activity data, the demographic information, theconsumer information, and/or the provider information may be provided byor obtained from one or more sources, e.g., the sources discussed abovewith reference to the activity data 214, the patient and/or populationdemographic information 216, the consumer profile information 218,and/or the care provider information 220.

In embodiments, the identifying component 254 can identify a populationof patients based on a set of criteria, which may, in one example, bereceived from a clinician device 240. In one or more embodiments, theset of criteria may include one or more medical conditions. In the sameor alternative embodiments, the set of criteria may include demographicinformation of one or more patients, such as age, gender, race, and/orlocation of residence. In one or more embodiments, the identifyingcomponent 254 may utilize any or all of the information and datareceived by the receiving component 252, such as: healthcare data, e.g.,the healthcare data present in one or more EMRs 212; activity data,e.g., the activity data 214; demographic information, e.g., the patientand/or population demographic information 216; consumer information,e.g., the consumer profile information 218; and provider information,e.g., the care provider information 220.

In embodiments, the identifying component 254 can identify a subset ofthe healthcare data associated with an individual patient related to aparticular medical condition of interest. In the same or alternativeembodiments, the identifying component 254 can identify one or morepatients in a population of patients having a medical condition ofinterest. In various embodiments, the identifying component 254 canidentify healthcare data and/or a patient in a population of patientsassociated with any medical condition of interest. In variousembodiments, data associated with one or more patients identified by theidentifying component 254 may be provided to one or more outputregistries, such as the one or more output registry databases 230.

In certain embodiments, to identify as many people as possible in apopulation that may have or have a particular medical condition ofinterest, the identifying component 254 may utilize clinical data, suchas lab test results, in combination with other healthcare data. In suchembodiments, the particular medical condition can be any condition wherespecific types of clinical information, e.g., lab test results, may beused to identify one or more patients that have or may have thatcondition. Exemplary conditions may include, but are not limited to,diabetes and heart disease. For example, in embodiments, the identifyingcomponent 254 may utilize diagnostic information, medicationinformation, and/or one or more lab test results to identify a patientas having or potentially having diabetes. In such embodiments, by havingthe identifying component 254 utilize information from one or more labtest results, the identifying component 254 may identify one or morepatients that have diabetes or may have diabetes, even if they have notbeen formally diagnosed with diabetes or have not been prescribeddiabetes medication. In the same or alternative embodiments, theidentifying component 254 may utilize lab test results in combinationwith other healthcare data to identify pre-condition patients, which mayallow early intervention to prevent a patient from developing aparticular condition.

In one or more embodiments, the identifying component 254 can identifysubsets of a population not based on a medical condition. For instance,in such embodiments, the identifying component 254 can identify subsetsof a population based on aspects of one or more patients in a populationof patients, e.g., age, gender, primary spoken language, income level,healthcare motivation level, education level, technology access (e.g.,phone, computer, etc.), contact preferences, work status (student,full-time, unemployed, retired, etc.), healthcare facility visit historyand frequency, advanced directives, and/or consumer profile information.In embodiments, the identifying component 254 can identify specific careprovider information, such as address and contact information of ahealthcare facility, primary spoken language of the healthcare facility,status on acceptance of new patients, etc. In one or more embodiments,the identifying component 254 can identify population and or communitybased resources, such as fitness centers, pharmacies, food banks, publicassistance, homeless shelters, etc.

In various embodiments, the identifying component 254 can identifysubsets of a population based on non-medical aspects of patients,specific care provider information, and/or population and/or communitybased resources in order to enable actions and care planning, measurecompliance, improve care transitions, optimize utilization of resources,and contain costs. In such embodiments, the identifying component 254can identify subsets of a population based on non-medical aspects ofpatients, specific care provider information, and/or population and/orcommunity based resources and populate such subsets into an outputregistry 230. Further, in such embodiments, the identified subsets canbe utilized by other components of the population health server 250,such as the stratifying component 256 and/or the prediction component262. Exemplary identification processes that may be performed, at leastin part, by the identifying component 254 are further discussed belowwith reference to FIGS. 3 and 9.

In embodiments, the stratifying component 256 can stratify a populationof patients based on one or more algorithms. In certain embodiments, thepopulation of patients may include at least a portion or all of thepopulation of patients identified by the identifying component 254. Inone or more embodiments, the stratifying component 256 may receive data(such as a listing of names or identification information) of at least aportion of the population of patients from the identifying component 254via the network 210. In the same or alternative embodiments, thestratifying component 256 may receive data (such as a listing of namesor identification information) of at least a portion of the populationof patients from the output registry databases 230 via the network 210.

In one or more embodiments, the stratifying component 256 can stratify apopulation of patients based on a clinically relevant algorithm. In suchembodiments, the clinically relevant algorithm may utilize clinicaldata. In one or more embodiments, the clinical data may be provided fromone or more EMRs, such as the EMRs 212. For example, in embodiments, theclinical data may include one or more of medication information,laboratory values, diagnostics, clinical narratives, and clinicianassessments. In the same or alternative embodiments, the clinical datamay include data obtained from the natural language processing of one ormore clinical assessments and/or clinical narratives. In certainembodiments, the stratifying component 256 can stratify a population ofpatients based on diagnostic codes, intervention codes, insuranceclaims, and/or medication information associated with each patient. Inone or more embodiments, the output of one or more algorithms associatedwith the stratifying component 256 may be provided to an output registrythat may be, for example, stored in one of the output registry databases230. In certain embodiments, an output registry can be updated whenadditional healthcare data, e.g., clinical data, is available for analgorithm, e.g., a clinically relevant algorithm, to utilize. In suchembodiments, the stratifying component 256 may re-stratify a populationof patients when such additional clinical data is available for theclinically relevant algorithm to utilize.

In various embodiments, the stratifying component 256 can stratify apopulation of patients into one or more groups, where the one or moregroups can include a plurality of patients having at least onesubstantially similar attribute. In such embodiments, the substantiallysimilar attributes can include one or more of disease risk levels and/orscores, one or more disease stages, and/or one or more healthcareobjectives. For example, in certain embodiments, the stratifyingcomponent 256 can stratify a population of patients, such as apopulation of patients identified as having or potentially havingdiabetes, into at least two groups corresponding to Type I and Type IIdiabetes. In certain embodiments, as discussed below with reference tothe output component 260, a clinician may be provided an opportunity toconfirm the output of one or more algorithms, such as an algorithmutilized with the stratifying component 256.

In one or more embodiments, the stratifying component 256 may stratifyinformation unrelated to specific medical conditions. For example, incertain embodiments, the stratifying component 256 can stratify a subsetof care providers based on venue location, specialty, spoken language,turn-over rate, readmission rate, patient satisfaction, availability,etc. Further, in certain embodiments, the stratifying component 256 canstratify one or more patients based on medical and/or prescriptioncompliance level, socioeconomic status, associated healthcare supportsystem, and/or utilization level of healthcare facilities (includingpharmacies).

In one embodiment, an exemplary stratification process to stratify oneor more patients with respect to medication compliance, which may be atleast partly performed by the stratification component 256, can includestratifying individual patients as having a low, medium, or highmedication compliance risk based on information related to the abilityto access a pharmacy, the ability to pay for medications, and/or thepresence of medication gaps in the healthcare record.

In certain embodiments, another exemplary stratification process tostratify one or more patients with respect to visit compliance, whichmay be at least partly performed by the stratification component 256,can include stratifying patients as having a high, medium, or low visitcompliance level for any or all of the various types of healthcarevenues. In such embodiments, individual patients may be stratified basedon the number of appointments made, the number of appointmentsscheduled, the number of appointments attended, the number of missedappointments, the type of appointment, the date and time of theappointment, the visit location, the venue, and whether or not thepatient acknowledged the appointment (e.g., was the patient aware of theappointment).

In one or more embodiments, another exemplary stratification process tostratify one or more patients with respect to their compliance forfilling prescriptions, which may be at least partly performed by thestratification component 256, can include stratifying patients as havinga low, medium, or high level of compliance with filling prescriptionsbased, at least in part, on the number of prescriptions written, thenumber of prescriptions filled, and the date and time the prescriptionswere filled.

In another embodiment, an exemplary stratification process to stratifyone or more patients as having one or more specific socioeconomicbarriers to healthcare, which may be at least partly performed by thestratification component 256, can include stratifying one or morepatients based on socioeconomic indicators, such as address, employmentstatus, marital status, education level, age, sex, dependents, race,ethnicity, insurance status, and primary spoken language.

In one embodiment, an exemplary stratification process to stratify oneor more patients as having a low, medium, or high level of supportoutside of a healthcare facility, which may be at least partly performedby the stratification component 256, can include stratifying one or morepatients based, at least in part, on a patient living situation, maritalstatus, disposition, caregiver status, and/or likelihood of utilizationof resources (family, personal, professional, community, etc.).

In another embodiment, an exemplary stratification process to stratifyone or more patients as having a low, medium, or high level ofhealthcare services utilization, which may be at least partly performedby the stratification component 256, can include stratifying one or morepatients based, at least in part, on the number of provider visits,claims data, facility visits, and medication usage. Additional exemplarystratification processes, which, in embodiments, may be at leastpartially performed by the stratification component 256, are describedbelow with reference to FIGS. 4 and 10.

In embodiments, the creating component 258 can create one or more outputregistries for one or more groups of patients of a population ofpatients, e.g., one or more groups identified and/or created by theidentifying component 254 and/or the stratifying component 256. Theoutput registries may account for resources available to a patient,lifestyle and prognostic assets that can be used for prediction, andassets necessary for attribution, allocation, or measurement. The outputregistries may be stored in one or more output registry databases 230and may be accessible via the network 210. In certain embodiments, theoutput registries may include patient data relevant to a population ofpatients.

As discussed above, the stratifying component 256 may re-stratify one ormore patients when additional healthcare data is available for astratification algorithm to utilize. In such embodiments, the creatingcomponent 258 may update one or more output registries based on such are-stratification of one or more patients.

In certain embodiments, by having particular patients in a particularregistry associated with a specific medical condition, e.g., a registryhaving patients with Type I diabetes, a health system may be able toprovide proposed plans specific to at least a portion of the patients ina particular registry. For example, in one embodiment, a Type I diabetesregistry may be utilized to provide a proposed plan of care for a Type Idiabetic patient, and a Type II diabetes registry may be utilized toprovide a proposed plan of care for a Type II diabetic patient. In suchembodiments, the proposed plans of care for the Type I and Type IIdiabetic patients may be different.

In embodiments, the output component 260 can provide clinicalqualification of algorithm output, such as an algorithm utilized withthe stratifying component 256. For example, in embodiments, a clinicianmay be provided an opportunity to see the data utilized by thestratifying component 256 to confirm the output of one or morealgorithms. In the same or alternative embodiments, a clinician may beprovided an opportunity to change the stratification level assigned toone or more patients. For example, in one embodiment, a clinician maychange the heart failure classification of one or more patients after anin-person examination and/or after looking at the healthcare recordsassociated with the one or more patients. In certain embodiments, theclinician may also have the opportunity to comment on the output and/ormake additional decisions (e.g., prescriptions, interventions, and thelike) based on the output.

In embodiments, the prediction component 262 can provide a prediction ofproblems or avoidable complications and can trigger events and alertsassociated with the patient. In certain embodiments, the healthcareprovider may also be provided with a prediction of problems the patientmay encounter. In the same or alternative embodiments, the healthcareprovider can also trigger events to happen, send alerts to people, andidentify the potential of having an avoidable complication within thenext twelve months. For example, the prediction component 262 mayindicate that a patient has a high risk of a heart related issue, andtrigger events and/or alerts so that the patient is seen by acardiologist, is checked more frequently, and is confirmed to be takingthe appropriate prophylactic medication. In certain embodiments, theprediction component 262 can predict: patient compliance levels forvarious treatments or medications; the need for transition care;readmission rates, emergency department re-entry rates, futurehealthcare costs; future patient attrition; comorbidity trending; and/orthe amount of care provider resources needed based on patient populationinformation.

In embodiments, the consolidation component 264 can consolidate thehealthcare data for a patient across all venues and healthcarefacilities, e.g., for any or all of the EMRs 212 associated with aparticular patient. In such embodiments, this can allow all clinicalsupport decisions across all venues and programs to be consolidated forthe patient. In other words, the consolidation component 264 mayconsolidate data without regard to a specific condition or venue. Inembodiments, the consolidation component 264 can piece togetherinformation from all programs that have been alerted or notified orfound something out about a patient and consolidate that information foruse by a healthcare provider when treating the patient.

In embodiments, the worklist component 266 can provide a filterableworklist for at least a portion of information contained in one or moreregistries, such as a registry in the output registry database 230. Insuch embodiments, a worklist may include a patient's name, risk level,location, clinical issues and alerts, care planning, payer information,demographics, medication information, and/or appointments. In the sameor alternative embodiments, the worklist can include a list of patientsfrom a registry, such as a registry in the output registry database 230,where the patients may be associated with a substantially similarmedical condition. Further, the worklist may support, across multiplevenues, multiple providers, and/or multiple conditions, providingactionable decision support tools and interventions, linking betweenapplications and enabling documentation for one or more healthcareproviders.

In embodiments, a worklist can link or connect information and workflowsfrom separate venues (and across a community). In such embodiments, theworklist may be a reference point for healthcare providers, includingcare managers, specialist providers, and primary care providers. In oneor more embodiments, the worklist may be parsed by healthcare providers,venue, and/or condition.

In embodiments, the worklist can provide a manageable list ofcross-continuum, cohort specific patients that may be available to ahealthcare provider or administrative body. In certain embodiments, theworklist may include criteria specific to the condition of interest,such as demographic factors, type and severity of disease, risk factors,and locality. In such embodiments, the worklist can providecontextuality of the designated cohort to the end-user, e.g., thehealthcare provider, and enable efficiencies for population surveillanceand resource allocation. In certain embodiments, the worklist may enablecross-continuum monitoring of a variety of activities by providing forthe end-user, e.g., the healthcare provider, the ability to monitorevents that have occurred or are occurring in near real-time, e.g.,within 1 minute, 10 minutes, 30 minutes, 60 minutes, 120 minutes, 240minutes, or 480 minutes of the event, outside of any one particulartransactional system or EMR domain. In embodiments, the worklist maysupport actionable decision support tools and linking betweenapplications to assist healthcare providers in the care of conditionspecified populations.

In one or more embodiments, the worklist may be a near real-time dynamiclist of patients from a cohort. As used herein, near real-time dynamiclist can mean a dynamic list that contains updated information that isavailable for viewing within at least about 1 minute, 10 minutes, 30minutes, 60 minutes, 120 minutes, 240 minutes, or 480 minutes of suchinformation being inputted into an associated population healthmanagement system. In certain embodiments, a worklist can enable ahealthcare provider to identify patients in a particular program andunderstand tasks that need to be performed by the healthcare provider orothers, as well as identify the status of those tasks. For example, in ahypertension care program setting, a worklist may enable a healthcareprovider managing a particular group of patients with hypertension todetermine how often their blood pressure should be monitored. Inembodiments, if data elements are missing on a particular patient, thehealthcare provider may be provided details in a historical and/orlongitudinal view. In such embodiments, the details in a historicaland/or longitudinal view can enable the healthcare provider todetermine: if an appointment was set; if a call to the patient isneeded, if help scheduling an appointment is needed; if help getting aprescription filled is needed; if a prescription was not filled; and/orwhy a patient missed an appointment (e.g., no ride, no money, forgot, inhospital somewhere, etc.). A worklist may also enable one or morehealthcare providers to send out group communications or announcementsand filter such communications or announcements by venue. Further, inone or more embodiments, a worklist may facilitate interventions. Incertain embodiments, a worklist may be dynamic and automaticallyrepopulate as patients enter or are removed from a particular careprogram.

In embodiments, the worklist may be a standalone application and/orinterface, e.g., the worklist may be available to end-users, e.g.,healthcare providers, agnostic of EMRs or a transactional system. Incertain embodiments, the worklist may comprise rows of patient names,columns to represent a variety of topics, and/or filtering capability toallow for individual use preferences. In such embodiments, examples ofcolumns (which may be flexible based on the condition of interest) mayinclude risk level, location, clinical issues/alerts, care planning,payer, demographics, medication information, and/or appointments. Inaddition to filtering, in embodiments, the worklists may facilitatelinking, documentation, notes, and the like, all from a single sourceacross venues. Exemplary worklists, which, in embodiments, may be atleast partially created by the worklist component 266, are depicted inFIGS. 16, 17, and 18.

In embodiments, the situational component 268 can provide a patientspecific preview that includes consolidated data across multipleproviders, venues, and conditions to facilitate care by one or morehealthcare providers. The situational component 268 may connecthealthcare providers and/or end-users to a consistent flow ofinformation from the population health management system 200, and mayprovide an efficient view of outputs without interrupting, and mayenable cross-venue/cross-role communications. In embodiments, thesituational component 268 may be patient-specific, but may consolidateand reconcile information across condition based programs.

In certain embodiments, the situational component 268 can capture anddisplay time sensitive, patient-specific information within the purviewof multiple, cross-continuum healthcare providers and may providepatient-specific information that has been generated from the populationhealth management system 200.

In embodiments, the situational component 268 can provide a patientspecific preview within a single view on a portion of a home page orviewing page. In one or more embodiments, the patient specific previewmay operate across multiple programs/conditions while remainingpatient-specific. In various embodiments, at least a portion of theconsolidated information may be provided directly or indirectly from theconsolidation component 264. In embodiments, the patient specificpreview can provide alerts, notifications, registry identification,program enrollment, model predictions, and time sensitive events ofinterest for a patient. For example, in such embodiments, the previewmay indicate that a patient was recently enrolled in a diabetesregistry, provided an alert that the patient was admitted to skillednursing without an appropriate diet order, that the patient has notreceived a flu shot, and that the patient has missed the last twoappointments with an orthopedic surgeon. In various embodiments, one ormore of the alerts, notifications, or other information may expire aftera given time period so as to not crowd the situational view withuntimely information. For example, in embodiments, a notification thatthe patient has not taken a flu shot will only be shown shortly beforeand during a flu season and will not be shown after the flu season. Inanother embodiment, information may be available for viewing over timeand may not be eliminated from view once the first healthcare providerhas seen the information.

In certain embodiments, the situational component 268 may indicate anevent or situation has occurred, or may occur, and this information maysequentially reveal the time of events. In the same or alternativeembodiments, the situational component 268 may allow for flagging ofparticular events of interest for communication with additionalproviders. An exemplary situational view, which, in embodiments, may beat least partially created by the situational component 268, is depictedin FIG. 17.

In embodiments, the natural language processing component 270 canextract information, e.g., clinical indicators, from at least a portionof one or more patient's health records, such as the health recordsassociated with one or more EMRs 212. In such embodiments, the naturallanguage processing component 270 can extract information from clinicaldata, which may include clinical impressions and/or clinical narrativesfrom one or more healthcare providers. In embodiments, the clinicalimpressions and/or clinical narratives may be associated with one ormore of: a patient's condition, a course of treatment for a patient, aplan of treatment for a patient, diagnostic tests, specialty studies,pathology reports, and operative reports. The natural languageprocessing component 270 can utilize any natural language processingtechnology known to one skilled in the art, as long as such technologyis capable of extracting information from clinical impressions and/orclinical narratives.

In certain embodiments, the natural language processing component 270may extract, from healthcare data, one or more clinical indicators thatmay be associated with one or more chronic conditions. In suchembodiments, the chronic conditions may include heart failure, acutekidney injury, chronic kidney disease, malnutrition, COPD, asthma,musculoskeletal diseases, cancer, acute infections, HIV, and/orautoimmune diseases. In various embodiments, by having extracted data,e.g., clinical indicators related to one or more chronic conditions, thepopulation health server 250, e.g. via the stratifying component 256,may be able to stratify one or more patients into one or more clinicalstages or classes of a chronic disease.

In certain embodiments, the natural language processing component 270may qualify clinical assessments. This is because a clinical assessmentfrom one healthcare provider may be more relevant than a clinicalassessment from another healthcare provider. For example, a clinicalassessment relating to heart failure can be weighted more when comingfrom a cardiologist compared to a heart failure assessment from anemergency room physician. In this regard, the natural languageprocessing component 270 may parse subjective or judgment terms tonon-discrete information such as clinical documentation or dictation(e.g., impression, course, plan, etc.) as well as interpretation of testresults or diagnostics (e.g., x-ray, echocardiogram, electrocardiogram,pathology reports, stress test, pulmonary functions, operative reports,and the like). Accordingly, in embodiments, the natural languageprocessing component 270 may provide a relevance rating to one or moreclinical indicators extracted from the healthcare data. In suchembodiments, the relevance rating may be based on the expertise of ahealthcare provider that is associated with each of the extractedclinical indicators. These relevance ratings may be applied to suchextracted information in order to better inform the appropriatehealthcare provider when viewing such information. In certainembodiments, a clinical assessment from a physician that does notspecialize in that particular field to which the assessment relates maybe flagged as needing a second opinion or as needing validation by aparticular specialist.

Generally, the antibiogram component 272 provides a flexible report thatprovides susceptibility rates based on selected populations. The crossvenue or population based antibiogram allows providers to viewsusceptibility trends based on institution, physician practice, zipcode, city, state, region, or country. Current antibiograms focus solelyon inpatients or outpatients and do not take into account additionalfactors amongst patients that can impact the effectiveness of the morecommonly prescribed antimicrobials. Prescribing an ineffectiveantimicrobial based on the overall population can lead to significantdelays in the patient's recovery. Allowing the provider to see whichantimicrobials will be most effective based on the patientscircumstances and region allows for better prescribing practices.Currently, antibiograms are only available for a subset of patients andare limited in their ability to display results based on patientpopulations outside of the hospital.

The cross venue antibiogram is based on a data set that includessusceptibility results from testing performed on inpatients,outpatients, and results from patients within the community, outside ofthe hospital setting. This data set contains basic patient demographics,but does not include patient identifiers. Antibiogram reporting isavailable using this data set allowing the provider to filter theresults returned by various demographic parameters. As described herein,these parameters may include, but not be limited to institution,physician practice, zip code, city, state, region, or country.Collectively, the information provided by the cross venue antibiogramallows the prescriber to more accurately prescribe medications, providesa broader view of susceptibility result trends overall, improveinfectious disease outcomes, is powerful for use across venues andagencies, and includes public health implications.

In embodiments, antibiogram component 272 receives medicationsinformation from disparate data sources. The data sources may includemultiple venues, multiple providers, or across multiple conditions. Forexample, medications information may be received from one or more EMRs212, each of which may be independent from one another. As describedherein, the EMRs 212 may span multiple applications, multiple providers,multiple patients, multiple conditions, multiple venues, multiplefacilities, multiple organizations, and/or multiple communities.

Susceptibility results may be received based on testing associated withpatient information provided by the disparate sources. Thesusceptibility results may also be received from the one or more EMRs212. The susceptibility results may indicate, at a population level,culture results for bacteria, fungus, viruses, and the like, that arefound in a particular population. In this regard, drug resistance, drugeffectiveness, and drug utilization may be received.

A cross venue antibiogram may be created based on the medicationsinformation and the susceptibility results. The cross venue antibiogramenables the population health server 250 to create an antibiogram thatis not restricted to a single institution or by stale data. Rather thecross venue antibiogram may be created in real-time based on theinformation received by various components of the population healthserver 250. This allows both a clinician and the population to see howto manage or identify increased resistant patterns, switch pharmacies(i.e., if one particular pharmacy is supplying an ineffective medicationthat is otherwise not identified in the increased resistant patterns),and the like.

The antibiogram may account for bacteria, fungus, viruses, and the likethat are found in a particular community as well as the medications(e.g., antibiotics, antihypertensives, anticoagulants) that are mosteffective, those that are not effective, and susceptibility. Theantibiogram may be stored in one or more antibiograms databases 235 andmay be accessible via the network 210. The antibiogram includesantibiogram data relevant to a population of patients. The antibiogramdatabases 235 may be a networked storage or distributed storageincluding storage on servers located in the cloud. Thus, it iscontemplated that for some embodiments, the information stored in theantibiogram databases 235 is not stored in the same physical location.The information within the antibiogram databases 235 may exist in avariety of standardized formats including, for example, narratives andother data. Information in the antibiogram databases 235 may becategorized or classified according to, for example, claims, diagnoses,wellness, satisfaction, population directories, and the like.

Each antibiogram may be used by, for example, a healthcare organizationto manage or identify resistant patterns for a population segment. Eachantibiogram may be condition specific. By way of example, a healthcareorganization or clinician may manage diabetic patients within aproscribed geographic area. The condition in this case is diabetesmellitus and the antibiogram databases 235 may help the healthcareorganization manage a population segment with this condition differentlyfor a particular resistant pattern than another population.

In embodiments, filtering of the antibiogram enables reporting based onselected demographics. The selected demographics may include aninstitution, a practice associated with a clinician, a zip code, acounty, a city, a state, a region, or a country. The selecteddemographics may further include a diagnosis, condition, or stateassociated with the patient. Selections can be made by a clinician, suchas from device 240 (e.g., a clinician device). Upon making theseselections, a filtered antibiogram may be presented on the device 240 inaccordance with the selections. For example, a clinician may be treatinga diabetes patient with a particular bacterial infection. The clinicianmay select demographics associated with the diagnosis, condition,location, and the like to enable the clinician to prescribe the mosteffective treatment based on the selections.

Generally, the medication advisor component 274 provides a prescriberfocused tool that provides dosing, cost, susceptibility, andavailability information for the prescriber to consider prior to placinga medication order. The comprehensive medication advisor is a prescriberorder entry tool that provides more information face up to theprescriber that is important to evaluate before the medication order isentered. The advisor may be functional in all healthcare settings andmay contain dosing recommendations for common disease states includingbut not limited to infectious diseases, coagulopathy, hypertension, andhyperlipidemia.

Current prescriber order entry tools are a valuable way to preventmedication errors and influence drug choice. However, the current toolslack the ability to provide a complete picture of additional factorssuch as cost and availability and, for antimicrobials, susceptibilitydata. By including cost, availability, and susceptibility data, thecomprehensive medication advisor disclosed herein enables clinicians toprescribe the most appropriate medication for their patient.

The comprehensive medication advisor described herein providesinformation to clinicians when they are prescribing medication that mayexpedite the prescribing process and prevent prescribing errors.Providing cost, availability, and susceptibility information during theorder entry process may expedite prescriber workflow, improve outcomes,prevent medication errors, and reduce drug expenditures.

When a prescriber opens the advisor for a specific disease state, theadvisor may contain multiple appropriate medication options. The cost,availability, and susceptibility information (when appropriate) may alsobe available for the prescriber to view prior to prescribing amedication. Cost may be shown in the most appropriate format, includingbut not limited to relative cost, actual wholesale price, institutioncost, or patient cost. Availability may be displayed using numericalamount or relative amount of drug in stock. Susceptibility data may beprovided for antimicrobials by incorporating the most appropriateantibiogram data, such as may be provided by antibiogram component 272.As such, the susceptibility data may include information relevant to oneor more of the individual patient, institution, physician practice, zipcode, city, state, region, or country.

Information provided by the comprehensive medication advisor mayexpedite prescriber workflow by providing the clinician with theinformation necessary to accurately prescribe medications, preservestock when drug shortages occur, reduce drug expenditures, improveinfectious disease outcomes, and/or enable evidence based decisionsupport for prescribing providers.

In embodiments, medication advisor component 274 receives a specificdisease state for a patient. The specific disease state may becommunicated by a clinician via a device 240, such as a cliniciandevice. The specific disease state may be received automatically via anEMR 212. The disease state may be utilized to further filter theantibiogram, as described above, to help a clinician identify anantibiogram specific to the disease state associated with a particularpatient.

In embodiments, related conditions, laboratory results, and allergyinformation for the patient are received, via one or more data sources(e.g., the EMR 212), by the medication advisor component 274. Each ofthe related conditions, laboratory results, and allergy information mayfurther influence how the clinician filters the antibiogram to provide apatient-centric antibiogram. In an embodiment, each of the relatedconditions, laboratory results, and allergy information may be providedto the antibiogram component 272 automatically, via one or more datasources (e.g., the EMR 212), to create the patient-centric antibiogramthat is displayed on the clinician device. Further information mayinclude genomic information and may be similarly provided to theantibiogram component 272.

In embodiments, multiple medication options are provided for thepatient. The medication options may include generic alternatives, cost,availability, and susceptibility information. In embodiments, thegeneric alternatives for a particular medication are provided to theclinician device. In embodiments, the cost for a medication or each ofthe generic alternatives is provided to the clinician device 240. Thecost may include relative cost, actual wholesale price, institutioncost, patient cost, or cost effectiveness. Cost effectiveness may factorin susceptibility information. In embodiments, availability of amedication is provided to the clinician device 240. The availability mayinclude a numerical amount or relative amount of a drug in stock.

In embodiments, susceptibility information is provided to the cliniciandevice. The susceptibility information is based on the antibiogram andmay include information relevant to one or more of the patient, aninstitution, a practice associated with a clinician, a zip code, acounty, a city, a state, a region, or a country. Each of these items ofinformation provided to clinician device allows the clinician toidentify, without influence (e.g., drug rep, etc.), the proper formularyof drug included within the ordering framework and provide the patientinformation that may help the clinician and patient select the mostappropriate medication.

Generally, medication stewardship component 276 provides an ability toassess for inappropriate drug utilization as well as trends within apopulation of people at multiple levels. For example, an assessment canbe made within a physician practice, an outpatient facility, a long termcare facility, a community, a city, a state, and/or a country. In anembodiment, the medication stewardship component 276 is utilized toassess antibiotic use in an inpatient setting. In this regard, directfeedback may be provided to prescribers if a particular use is deemedinappropriate. The assessment may consider, in embodiments,susceptibility information is based on the antibiogram and may includeinformation relevant to one or more of the patient, an institution, apractice associated with a clinician, a zip code, a county, a city, astate, a region, or a country. Additionally or alternatively, theassessment may consider specific clinical data relevant to a particularpatient. This feedback may be utilized to reduce medication misuse,errors, and healthcare costs, while improving outcomes.

For example, in acute care settings, prescribing and patient monitoringoversight is frequently provided by a secondary healthcare provider suchas a pharmacist or nurse. Prescribing guidance may also be provided viarestricted formularies and prescribing guidelines. However, similaroversight in non-acute care settings is not possible because currenthealthcare systems are not able to account for patients in non-acutecare settings taking multiple medications prescribed by differentphysicians and/or filled at separate pharmacies. Medication stewardshipcomponent 276 monitors each of these variables and provides feedback atthe individual patient-level, as well as for entire populations ofpeople for evaluation of medication misuse events as well as trends. Inthis regard, medication stewardship component 276 reduces medicationmisuse, medication errors, and healthcare costs.

In embodiments, trends of inappropriate medication use may be evaluatedor monitored by medication stewardship component 276. Additionally,emerging trends in treatment failure or ineffectiveness (e.g.,antimicrobial resistance) may quickly be identified by utilizinginformation received from other components of the population healthserver 250 (e.g., antibiogram component 272, medication advisorcomponent 274, and the like). Patient adherence or lack thereof may alsobe monitored by medication stewardship component 276. Drug-druginteractions may be detected by medication stewardship component 276 forpatients who use multiple pharmacies. Medication stewardship component276 may assess if patients are being properly monitored and educated andmay predict patient or clinician non-compliance as well as the need foradditional education. Provider prescribing trends and effects ofintervention may also be monitored by medication stewardship component276.

In embodiments, medication stewardship component 276 monitors and flagsinappropriate trends and may alert or notify medication stewards tointervene. In embodiments, medication stewardship component 276 flagsand alerts medication stewards to intervene for development ofantimicrobial resistance, unnecessary prescriptions, incorrect or morecostly medications, neglecting to order follow up laboratories tomonitor for adverse drug reactions, patients not refilling medicationsas prescribed, and/or drug interactions from patients using multiplepharmacies and/or providers.

In an embodiment, medication stewardship component 276 documentsinterventions via an automated messaging system. In another embodiment,interventions may be documented manually, such as via a device 240, andstored by the medication stewardship component 276. Outcomes of theinterventions may be similarly documented or stored by medicationstewardship component 276. In this regard, both trending and reportingis enabled by medication stewardship component 276. In addition toantimicrobials, medication stewardship component 276 may additionallymonitor and improve utilization for antihypertensives,antihyperlipidemics, analgesics, and anticoagulants.

The management component 278 may provide information associated withmanaging a population of patients for a particular health system. In oneor more embodiments, the management component 278 may utilize data fromone or more EMRs 212, activity data 214, demographics 216, and/or careprovider information 220 to consolidate, process, and analyzeinformation, and alert a manager or healthcare provider to metrics thatare not within a predetermined range. In addition, in such embodiments,the management component 278 may provide an overview of the healthsystem and the population of patients associated therewith.

In certain embodiments, the management component 278 may provideinformation on the health system and/or on at least a portion of apopulation of patients within the health system. For example, in suchembodiments, this information may include one or more metrics to assessutilization of the facilities and/or services associated with the healthsystem. Further, in embodiments, this information may include any typeof financial information associated with the health system. In one ormore embodiments, the information may include an overview of variouscare programs operated by the health system. In certain embodiments, theinformation may include general population health metrics for thepatients associated with the health system, such as the percentage ofpatients having chronic conditions, rate of readmissions, etc. In one ormore embodiments, the information may include alerts to notify a manageror healthcare provider of issues to be addressed, such as low compliancewith follow-up appointments, with getting prescriptions filled, etc. Theinformation provided by the management component 278 may be presented inany fashion. Exemplary health system overviews that may be at leastpartly provided by the management component 278 are depicted in FIGS. 14and 15.

In certain embodiments, the management component 278 may provide aproposed plan to help allocate health system and/or healthcare resourcesavailable for a population of patients. For example, in suchembodiments, the management component 278 may find care providerresources, e.g., from the care provider information 220, that areavailable for a population of patients having a particular condition ofinterest. This may allow a healthcare provider and/or manager to betterallocate resources as necessary to accommodate the population ofpatients of interest. In one embodiment, the management component 278may utilize information associated with at least one output registry,such as an output registry stored in the output registries database 230,to provide a proposed plan to allocate health system and/or healthcareresources available for at least a portion of a population of patients.

In certain embodiments, the healthcare transition component 280 canfacilitate transition care for one or more patients. For example, in oneor more embodiments, the healthcare transition component 280 may utilizedata from one or more EMRs 212, demographics 216, and/or care providerinformation 220 to facilitate the arrangement of transition care. Insuch embodiments, the healthcare transition component 280 may providetransition care information to a healthcare provider so that thehealthcare provider can review the transition care arrangements with thepatient during an appointment with the healthcare provider.

The healthcare transition component 280 can facilitate any type oftransition care required for a patient. For example, in embodiments, thehealthcare transition component 280 can schedule an appointment for apatient and/or arrange transportation services for the patient. In oneembodiment, the healthcare transition component 280 can arrange for thedelivery of prescriptions and/or arrange for prescription assistance. Invarious other embodiments, the healthcare transition component 280 mayarrange follow-up services that may be needed for a patient, such assupport groups, dietary requirements, etc., and provide information fora healthcare provider to educate the patient about such services. Incertain embodiments, the healthcare transition component 280 maydetermine and notify a healthcare provider if a referral need exists fora certain patient. Further, in one or more embodiments, the healthcaretransition component 280 can facilitate the assignment of a particularhealthcare provider to a particular patient. Exemplary transition careprocesses, which, in embodiments, may be at least partially performed bythe healthcare transition component 280, are described below withreference to FIGS. 5-8 and 11-13.

In embodiments, the condition module 282 may be specific to one medicalcondition and one patient and provide associated information acrossmultiple venues. In such embodiments, the condition module 282 canprovide a patient- and condition-specific overview to allow healthcareproviders to monitor specific issues and see the story of the patient'scondition. In embodiments, the story conveyed by the condition component282 can include a longitudinal timeline of events related to thatcondition, such as the time of diagnosis, treatments, labs anddiagnostics related to condition, and quality measures. In certainembodiments, the condition component 282 may account for venue and maydisplay time relative information for more acutely collected data (i.e.for the hospitalized patient or acutely monitored patient).

In one or more embodiments, the condition component 282 may providevisibility to care teams involved, consultations, references, and/orquality measures as they relate to the condition of interest. In certainembodiments, the condition component 282 may provide a healthcareprovider access to disparate EMR's for more detailed informationassociated with the condition of interest while providing access toclinical decision support tools (such as care process maps, treatmentnomograms, etc.) for the condition of interest. In embodiments, thecondition component 282 can provide similar information across venuesand healthcare providers so that all healthcare providers will beaccessing similar condition information. In certain embodiments, thecondition component 282 may include specialist specific views orinformation, which can account for more complex care issues. The abilityto correlate and connect condition specific information from varioussystems for cross-continuum display may lessen the burden of potentialerrors, educate the community of providers responsible for this patient,and improve accuracy and efficiency for population management.

In certain embodiments, the condition component 282 can include acondition timeline or longitudinal record. In such embodiments, thislongitudinal record can provide a timeline of events related to theparticular condition of interest. The timeline of events may includelaboratory results, medications, diagnostics, and/or interventionsderived from the healthcare data from multiple venues, multipleproviders, and across multiple conditions. In embodiments, the timelinecan enable clinicians to quickly identify additional information about apatient with a particular condition of interest, even while reviewingdata originating from multiple data sources, multiple venues, ormultiple providers and even from multiple conditions.

In embodiments, the timeline may provide the clinician a longitudinalstory for a patient with a particular diagnosis or condition. Forexample, a clinician may have a diabetic patient. The timeline of eventsmay provide the clinician events related to diabetes over the last sixmonths that have occurred. The clinician may initially see normal bloodsugar and then identify, two weeks later, that the blood sugar waselevated. At this point, the clinician may identify that all otherlaboratory results were also high or off or find where the patientreceived an intervention with a specialist. Exemplary conditioncomponent information, which, in embodiments, may be at least partiallyprovided by the condition component 282, are described below withreference to FIGS. 18, 21, and 22.

In embodiments, the patient portal component 284 can providehealthcare-related information for a particular patient. In certainembodiments, the patient portal component 284 can allow the patient toview their healthcare data and the outputs of any program algorithms,such as an identification algorithm and/or a stratification algorithm.In one or more embodiments, the patient portal component 284 can provideaccess to educational information and workshops relevant to thepatient's health status or conditions. In certain embodiments, thepatient portal component 284 can allow the patient to input informationinto their healthcare record, such as exercise, diet, personal devicedata, payment information, etc. An exemplary patient portal, which, inembodiments, may be at least partially provided by the patient portalcomponent 284, is described below with reference to FIG. 27.

In certain embodiments, the baseline component 286 can consolidate basicinformation about a population, provider, or patient, and direct theidentification and stratification of appropriate parameters tofacilitate basic care operations. In one or more embodiments, thebaseline component 286 can consolidate information associated withidentified and/or stratified subsets of a patient population and canprovide care planning, improve care transitions, optimize resourceutilization; and/or contain costs. For example, in one embodiment,knowing that a patient is likely highly motivated for healthcarepurposes and has a high compliance rate, the baseline component 286 cannotify a healthcare provider and/or health system that they can rely onthe patient to comply with their care and need not spend resourcesunnecessarily. In certain embodiments, the baseline component 286 canprovide a holistic view of a population, provider and/or a patient andcan address and/or predict underlying gaps in care, notify appropriateproviders, patients, and family, and proactively manage these situationsprior to penalties or crises.

The population health management system 200 is an open-loop systemmeaning that as a healthcare organization utilizes the output of thepopulation health server 250, more organizational and patient data isgenerated which is fed back into the system 200 and used to update thevarious output registries 230, EMRs 212, and/or antibiograms 235.Further, the system 200 operates over and is compatible with existingelectronic medical record systems associated with healthcareorganizations, even if these electronic medical record systems aredisparate in nature. Thus, a healthcare organization can utilize thesystem to manage population health without having to incur significantfinancial costs to reconfigure its already-existing electronic medicalrecord system.

Turning now to FIG. 3, an exemplary identification algorithm 300 isdepicted for identifying patients that have or may have diabetes. Itshould be understood that the specific steps and the order of the stepsdepicted in the algorithm 300 are only exemplary and that other stepsand different orders of the steps may be user. In addition, it should beunderstood that other possible variations for the algorithm 300 arewithin the scope of the present invention.

In the embodiment depicted in FIG. 3, the identification algorithm 300may include a start step 302, where data associated with one or morepatients is received, and then at the step 304 the data is queried todetermine if the patient is greater than or equal to 18 years old. Ifthe patient is not greater than or equal to 18 years old, at step 306,the patient is excluded from the being populated in a diabetes registry.After a patient is determined to be greater than 18 years old thepatient information is queried to determined, at steps 308 if there is adiabetes code, and at step 310, if there is an insurance claims presentin the patient information. At step 314, if the one out the two criteriain steps 308 and 310 are present then at step 312, the patient ispopulated into a diabetes mellitus registry. In none of the two criteriain steps 308 and 310 are met, at step 316, it is determined if thepatient currently has gestational diabetes. If so, then at step 318,that patient is excluded from being populated in the diabetes registry.If the patient does not currently have gestational diabetes, then atstep 320, it is determined if the patient is currently oncorticosteroids. If so, then, at step 318, the patient is excluded.

If the patient does not currently on corticosteroids then, at step 322,it is determined if the patient is on diabetic medications. If so, thenit is determined, at step 324, if the patient is only on metformin, andif not, then the patient is populated in the diabetes mellitus registry.If the patient is not only on metformin, then at step 326, it isdetermined if the patient have ever been diagnosed with polycysticovarian syndrome (PCOS). If so, then at step 328, the patient isexcluded from being populated in the diabetes registry.

For a patient that is not on diabetic medications and has not been everdiagnosed with having PCOS, then, at step 330, it is determined if thepatient has any clinical laboratory data to suggest that the patient hasdiabetes. For instance, at step 332 the patient information is queriedto determine if there is laboratory data evidencing a AlC value greaterthan or equal to 6.5%. Further, at step 334, the patient information isqueried to determine if there is laboratory data evidencing if thefasting plasma glucose concentration is greater than or equal to 126mg/dL (7.0 mmol/L). In addition, at step 336, the patient information isqueried to determine if there is laboratory data evidencing a 2-hourplasma glucose concentration of greater than or equal to 200 mg/dL (11.1mmol/L) during an oral glucose tolerance test (OGTT). At step 338, it isdetermined if the patient has an abnormal result for any of the testsqueried for in steps 332, 334, and 336. If so, then the patientpopulates to the diabetes registry at step 312. If not, at step 340, thepatient is excluded from population in the diabetes registry.

FIG. 4 depicts an exemplary stratification algorithm 400 is depicted forstratifying one or more patients present in a diabetes registry. Itshould be understood that the specific steps and the order of the stepsdepicted in the algorithm 400 are only exemplary and that other stepsand different orders of the steps may be user. In addition, it should beunderstood that there other possible variations for the algorithm 400within the scope of the present invention.

At step 402, patient information associated with patients present in thediabetes registry is received. In certain embodiments, at the step 304,the information related to one or more patients in the diabetes registryis queried to determine if the patient information includes a coderelated to Type II diabetes within the last five years. If so, then atstep 406, the patient is stratified to be associated with Type IIdiabetes. If the patient information does not include a code related toType II diabetes within the last five years, at step 408, it isdetermined if the patient information includes a code related to Type Idiabetes within the last five years. If so, then, at step 410, thepatient is stratified to be associated with Type I diabetes. If thepatient does not include a code related to Type I diabetes within thelast five years, at step 412, it is determined if the patientinformation includes clinical data suggesting the presence of antibodiesto islet cells. If so, then, at step 410, the patient is stratified tobe associated with Type I diabetes. If the patient information does notinclude clinical data suggesting the presence of antibodies to isletcells, then at step 414, it is determined if the patient informationincludes clinical data that suggesting a C-peptide concentration of lessthan 0.4 ng/mL. If so, then, at step 410, the patient is stratified tobe associated with Type I diabetes. If the patient information does notinclude clinical data that suggesting a C-peptide concentration of lessthan 0.4 ng/mL, then at step 416, it is determined if the patient hasbeen prescribed diabetic medications other than insulin. If so, then atstep 406, the patient is stratified to be associated with Type IIdiabetes. If the patient has not been prescribed diabetic medicationsother than insulin, then at step 418, it is determined if the patienthas been prescribed insulin and no other diabetic medications. If so,then at step 410, the patient is stratified to be associated with Type Idiabetes. If not, then the patient is placed in the “other category”which is does not include patients stratified to be associated with TypeI or Type II diabetes.

As discussed above, in certain embodiments, a population healthmanagement system, e.g., the population health management system 200 ofFIG. 2, can aid in providing transition healthcare for one or morepatients. For example, in certain embodiments, a population healthserver may provide transition management care associated withtransportation of a patient to or from a healthcare venue for anappointment. FIG. 5 depicts one embodiment of an algorithm 500 that maybe used to determine a need for transportation for an appointment andif, based on the transportation situation of patient if an appointmentshould be scheduled. It should be understood that the specific steps andthe order of the steps depicted in the algorithm 500 are only exemplaryand that other steps and different orders of the steps may be user. Inaddition, it should be understood that there other possible variationsfor the algorithm 500 within the scope of the present invention.

At step 502, a population health management system receives and/orgenerates a generated provider list that may include one or morepatients in need of scheduling an appointment to see a healthcareprovider and may or may not have transportation needs. At step 504, itis determined if the patient has transportation needs, and if not, thenat step 506 an appointment is scheduled for the patient. If the patientdoes transportation needs, then at step 508, it is determined if thepatient's insurance will cover transportation services for healthcareprovider appointments. If so, then at step 506, an appointment isscheduled. If the patient's insurance will not cover transportationservices then, at step 510, it is determined if there are communityorganizations or free services that can provide transportation. If so,then at step 506, an appointment is scheduled. If there are no communityorganizations or free services that can provide transportation, then atstep 512, it is determined if there are other resources available thathave not been identified. If so, then at step 506, an appointment isscheduled. If there are no other resources available, then at step 514it is determined if there are home health or other service options forthis patient. If so, then the home health or other services are arrangedat step 518. If there is no home health or other service optionsavailable for the patient, then at step 516, the patients an appointmentis put on hold until transportation services become available.

FIG. 6 depicts another embodiment of an algorithm 600 that may beutilized to provide transition care by facilitating the provision ofmedications to a patient. It should be understood that the specificsteps and the order of the steps depicted in the algorithm 600 are onlyexemplary and that other steps and different orders of the steps may beuser. In addition, it should be understood that there other possiblevariations for the algorithm 600 within the scope of the presentinvention.

At step 602, a population health management system, e.g., the populationhealth management system 200 of FIG. 2, can determine that medicationfollow-up is needed for a patient. At step 604, it is determined if thepatient can access prescriptions, and if so, then at step 606, aprescription is sent to a pharmacy and communication with the patient isinitiated in order to arrange the pick-up of the medication. At step608, it is determined if the patient can access the pharmacy formedication pick up, and if so, then at step 614, the patient receivesthe medication. If the patient cannot access the pharmacy, then at step610, it is determined if the pharmacy can deliver the medication. If so,then at step 614, the patient receives the medication via delivery bythe pharmacy. If the pharmacy does not deliver and the patient cannotaccess the pharmacy, then at step 612 an online pharmacy or a suitablealternative pharmacy is located, where at step 614, the patient willreceive the medication.

If it is determined in step 604 that the patient cannot access theprescriptions, then at step 616, it is determined if there is aprescription assistance program (PAP) to help, and if so, at step 618 anapplication is submitted for the PAP. If a PAP is available to help andan application has been submitted at step 618, and/or if a PAP is notavailable to help, at step 620 it is determined if there are medicationsamples available. If there are samples available, then at step 622,samples are provided or arranged to be provided and PAP information isprovided or arranged to be provided. If there are no samples to beprovided, then at step 624 it is determined if there is a centralbilling office (CBO) that can provide medication assistance, and if so,at step 626, a referral is sent to the CBO. If there is not a CBO toprovide assistance, then at step 628, the care management may absorb thecost of medications in the short term.

FIG. 7 depicts another embodiment of an algorithm 700 that may beutilized to provide transition care by facilitating the provision ofadditional services for a patient. It should be understood that thespecific steps and the order of the steps depicted in the algorithm 700are only exemplary and that other steps and different orders of thesteps may be user. In addition, it should be understood that there otherpossible variations for the algorithm 700 within the scope of thepresent invention.

At step 702, it is determined that other services, such as follow upsupport, education, etc., may be necessary for the patient. At step 704,it is determined if additional referrals are required for the additionalservices, and if not, at step 706 the process stops. If additionalreferrals are required, it is determined if support groups, nutritionalconsultations, physical activity access, and education services areneeded at steps, 708, 710, 712, and 714, respectively. If any of theservices of steps 708, 710, 712, and 714 are needed, at step 716, it isdetermined if insurance will cover these services. If not, then at step718, it is determined if there are free services available. If there areno free services available, then at step 720, as a last resort, thehealthcare provider is directed to educate the patient at that time, ifpossible. If insurance will cover the services or there are freeservices available, then at step 722, a referral is sent. At step 724,the healthcare provider is directed to educate the patient regarding thearranged services and verify that the patient has access to and anunderstanding of the services. At step 726, a transportation workflow isinitiated to facilitate transportation to the services, if necessary,and at step 728 the process ends.

FIG. 8 depicts another embodiment of an algorithm 800 that may beutilized to provide transition management care, if necessary, bydetermining if a patient requires a referral. It should be understoodthat the specific steps and the order of the steps depicted in thealgorithm 800 are only exemplary and that other steps and differentorders of the steps may be user. In addition, it should be understoodthat there other possible variations for the algorithm 800 within thescope of the present invention.

At step 802, a population health management system, e.g., the populationhealth management system 200 of FIG. 2, may generate or provide patientsin a diabetes registry, e.g., an output registry in the registrydatabase 230 of FIG. 2. At step 804, it is determined if the algorithmwas initiated manually. If the algorithm was not initiated manually,then at step 806, it is determined if the patient has a primary careprovider (PCP). If the patient has a PCP, then at step 808, it isdetermined if the patient has Type I diabetes, Latent autoimmunediabetes of adults (LADA), or Maturity onset diabetes of the young(MODY). If not, then at step 810, the patient is stratified as havingType II diabetes. Then at step 812, it is determined if there arefactors that necessitate referral to an endocrinologist. Then at step814, it is determined if there is a patient request for anendocrinologist, if the patient. At step 816, it is determined if thepatient has been hospitalized for hyperglycemia. At step 818, it isdetermined if the patient is on two or more diabetic medications and hasan elevated HbAlC value greater than 7%. At step 820, it is determinedthe patient has had two consecutive HbAlC values greater than 7%. Atstep 822, it is determined if one or more of the criteria determined insteps 814, 816, 818, and 820 are met, and if not, then at step 824, theprocess ends and a referral is not provided. If one or more of thecriteria determined in steps 814, 816, 818, and 820 are met, or if thepatient has Type I diabetes, LADA, or MODY, then at step 826 it isdetermined if the patient has an endocrinologist. If the patient doeshave an endocrinologist, then at step 828, it is determined if thepatient has seen that specialist in the past year, and if so, then atstep 824, the process ends and a referral is not provided. If thepatient has not seen that specialist in the past year, or if the patientdoes not have an endocrinologist, then at step 830, it is determined ifa referral agent has been run for the combination of the user/healthcareprovider and the patient within the last 30 days. If so, then at step824, the process ends and a referral is not provided. If a referralagent has not been run for the combination of the user/healthcareprovider and the patient within the last 30 days, then at step 832 it isdetermined if the patient in the diabetes registry is an uncontrolleddiabetic. If so, then at step 850, it is determined if the patient hasan endocrinologist, and if so at step 852, the endocrinologist is placedfixed at the top of the list and is designated as the “currentendocrinologist.” After step 852, or if it is determined in step 850that the patient does not have an endocrinologist, at step 854, thesystem is queried for endocrinologist providers. Then at step 856, aprimary sort of an endocrinologist provider list by payor compatibilityis performed. Then at step 858 a secondary sort of the endocrinologistprovider list by language compatibility is performed. Then at step 860,a tertiary sort of the endocrinologist provider list by locationcompatibility is performed. Then at step 862, for the patients withuncontrolled diabetes, a list of endocrinologist providers is generatedfor the best match.

In addition, at step 834, for all the patients in the diabetes registry,it is determined if the patient has a PCP and if so, the PCP is placedfixed at the top of the list and designated as the “current PCP.”Regardless of whether the patient has a PCP or not, at step 838, thesystem is queried for PCP providers. At step 840, a primary sort of aPCP provider list by payor compatibility is performed. Then at step 842a secondary sort of the PCP provider list by language compatibility isperformed. Then at step 846, a tertiary sort of the PCP provider list bylocation compatibility is performed. Then at step 848, for all thepatients in the diabetes registry, a list of PCP providers is generatedfor the best match.

After steps 848 and 862, at step 864, a notification is formatted to theuser and includes the top 10 providers. At step 866, designations forPCPs and endocrinologists are provided. Then at step 868, appropriaterationale on a provider basis is provided. At step 870, an option toview the next ten providers is provider, and at step 872, the processends.

FIG. 9 depicts an exemplary identification algorithm 900 that may beutilized by a population health management system, e.g. the populationhealth management system 200 of FIG. 2, to identify patients that mayhave heart failure. It should be understood that the specific steps andthe order of the steps depicted in the algorithm 900 are only exemplaryand that other steps and different orders of the steps may be user. Inaddition, it should be understood that there other possible variationsfor the algorithm 900 within the scope of the present invention.

The identification algorithm 900 may include a start step 902, wheredata associated with one or more patients is received, and then at thestep 904 the data is queried to determine if the patient is less than 18years old. If not, then the patient is excluded from being identifiedwith heart failure. If the patient is not less than 18 years old, thenat step 908 it is determined if a diagnosis code for heart failure ispresent in the healthcare data. If so, then at step 912, the patient isincluded and identified as having or potentially having heart failure.If there is no diagnosis code for heart failure is present in thehealthcare data, then at step 910, it is determined if there is claimsdata present that suggests the patient has or may have heart failure. Ifso, then at step 912, the patient is included and identified as havingor potentially having heart failure. If the is no claims data presentthat suggests the patient has or may have heart failure, then at step914, it is determined if there is data that shows that an echocardiogramwas performed. If so, then at step 916, it is determined if there isdata for an ejection fraction (EF) quantitative results or other codesassociated with EF quantitative results. If there is such data or codespresent, at step 918, it is determined if the EF is less than 40%. Ifthe EF is less than 40%, then at step 920, the patient is identified ashaving or potentially having heart failure and is included in the heartfailure registry. If the EF is not less than 40%, then at step 922, itis determined if there is data evidencing moderate or severe systolicdysfunction. If so, then at step 920, the patient is identified ashaving or potentially having heart failure and is included in the heartfailure registry.

If there is no data evidencing moderate or severe systolic dysfunction,or if there is no EF quantitative results or other codes associated withEF quantitative results, or if no echocardiogram was performed, then thepatient's data is queried for the presence of several medications. Thepatient's data is queried for the presence of: ACE inhibitors andangiotensin II receptor blockers at step 926; beta blockers at step 928;nitrates and hydralazine at step 930; calcium channel blockers at step932; digoxin at step 934; loop diuretics at step 936; aldosteroneantagonists at step 938; and anticoagulants at step 940. Then at step942, it is determined if at least three of the heart failure medicationsqueried in steps 926, 928, 930, 932, 934, 936, 938, and 940 are present,and if so, then at step 944 the patient is identified as having orpotentially having heart failure and is included in the heart failureregistry. If less than three of the heart failure medications arepresent, then at step 946, the patient is not identified as having heartfailure and is not included in the registry.

FIG. 10 depicts an exemplary stratification algorithm 1000 is depictedfor stratifying one or more patients present in a heart failureregistry. It should be understood that the specific steps and the orderof the steps depicted in the algorithm 1000 are only exemplary and thatother steps and different orders of the steps may be user. In addition,it should be understood that there other possible variations for thealgorithm 1000 within the scope of the present invention.

At step 1002, data associated with the patients in the heart failureregistry are received. At step 1004, data from the patients in the heartfailure registry is filtered only to provide data within the past year,so that for steps 1006 through 1026, a New York Heart Association (NYHA)code can be determined or attempted to be determined for the patient. Atstep 1006, it is determined if discrete NYHA codes are available in thepatient's healthcare data. If so, then in step 1008, the NYHA code isassigned to the patient. If not, at step 1010, it is determined ifphysician notes are available for natural language processing fordetermining an NYHA code. If so, then at step 1012, it is determined ifthe patient is symptomatic at rest, and if so, in step 1020, the patientis assigned the NYHA IV code. If the patient is not symptomatic at rest,then in step 1014, it is determined if the patient is symptomatic withminimal exertion, and if so, in step 1022, the patient is assigned theNYHA III code. If the patient is not symptomatic with minimal exertion,then in step 1016, it is determined if the patient is symptomatic withmoderate exertion, and if so, in step 1024, the patient is assigned theNYHA II code. If the patient is not symptomatic with moderate exertion,then in step 1018, it is determined if the patient is asymptomatic, andif so, in step 1026, the patient is assigned the NYHA I code.

After assigning the NYHA code to the patient or not being able to assignan NYHA code to the patient, in step 1028, it is determined if AmericanMedical Association (AMA) codes are available in the patient'shealthcare data. If so, then in step 1030, the AMA code is assigned tothe patient. If no AMA codes are available in the patient's healthcaredata, then at step 1032, it is determined if there are physician notesavailable for natural language processing for determining an AMA code.If so, then in step 1034, it is determined if there is no evidence ofstructural heart damage. If so, then in step 1042, the patient isassigned the AMA code A. If there is not any evidence of structuralheart damage, then in step 1036, it is determined if the patient'ssymptoms are minimal or nonexistent. If the symptoms are minimal andnonexistent, then in step 1044, the patient is assigned the AMA code B.If the symptoms are not minimal and nonexistent, then in step 1038, itis determined if the symptoms are managed with therapy. If the symptomsare managed with therapy, then in step 1046, the patient is assigned theAMA code C. If the symptoms are not managed with therapy, then in step1040, it is determined if the patient has symptomatic heart disease thatdoes not respond to therapy, and if so, in step 1048, the patient isassigned the AMA code D.

After assigning the AMA code to the patient or not being able to assignan AMA code to the patient, in step 1050, the data from the patients inthe heart failure registry is filtered only to provide data within thepast year, so that for steps 1052 through 1076, Ejection Fraction (EF)classifications can be determined. In step 1052, it is determined if anechocardiogram has been performed. If not, then at step 1054, it isdetermined if an NV test has been performed. If not, then the processends and no EF classification is determined. If an NV test or anechocardiogram has been performed, then at step 1058, it is determinedif there are EF quantitative results. If so, at step 1062, it isdetermined if the EF quantitative results reveal an EF greater than 55%.If so, then the patient is classified as having a preserved EF at step1076. If the EF quantitative results do not reveal an EF greater than55%, then at step 1066, it is determined if the EF quantitative resultsreveal an EF greater than 40%. If so, in step 1074, the patient isclassified as having a moderate EF. If the EF quantitative results donot reveal an EF greater than 40%, then at step 1072, the patient isclassified as having a reduced EF.

If there are no quantitative EF results, at step 1060, it is determinedif there are EF qualitative results. If so, in step 1064, it isdetermined if there is no systolic dysfunction. If there is not systolicdysfunction, then in step 1076, the patient is classified as having apreserved EF. If it is determined that there is not no systolicdysfunction, then in step 1068, it is determined if the patient has mildsystolic dysfunction. If so, then the patient is classified as having amoderate EF in step 1074. If it is determined that the patient does nothave mild systolic dysfunction, then in step 1070, it is determined ifthe patient has moderate or severe systolic dysfunction. If so, thepatient is classified as having a reduced EF.

As discussed above, in certain embodiments, a population healthmanagement system, e.g., the population health management system 200 ofFIG. 2, can aid in providing transition management care for one or morepatients, such as determining if a referral is needed for a patient.FIG. 11 depicts one embodiment of an algorithm 1100 that may be used todetermine whether a patient needs a referral or not. It should beunderstood that the specific steps and the order of the steps depictedin the algorithm 1100 are only exemplary and that other steps anddifferent orders of the steps may be user. In addition, it should beunderstood that there other possible variations for the algorithm 1100within the scope of the present invention.

At step 1102 data from the patients in the heart failure registry and/orthe pre-heart failure registry is received. In step 1104, it isdetermined if the patient has a PCP. If so, then in step 1106, it isdetermined if the patient was stratified as having class BII-BIV, C, orD heart failure. If not, then in step 1108, it is determined if thepatient was stratified as having class A or BI heart failure. If so,then in step 1110, it is determined if the patient had an acute hospitaladmission during the prior two years for specific diseases or treatmentsas determined in steps 1112-1124. The specific diseases are pulmonaryedema, new onset atrial fibrillation, heart failure, coronary arterybypass grafting (CABG), acute myocardial infarction (AMI), valvulardisease, cardiomyopathy for steps 1112, 1114, 1116, 1118, 1120, 1122,and 1124, respectively. At step 1126, it is determined if one or more ofthe diseases or treatments of determined in 1112, 1114, 1116, 1118,1120, 1122, and 1124 occurred for the patient, If not, then the processends and no referral is made. If the patient has had one or more of thediseases or treatments of determined in 1112, 1114, 1116, 1118, 1120,1122, and 1124, or if the patient is stratified as having class BII-BIV,C, or D heart failure, in step 1132, it is determined if the patient hasa cardiologist. If so, in step 1130, it is determined if the patient hashad a cardiologist outpatient encounter within the last year. If so, instep 1128, the process ends and no referral is made. If the patient hasnot had a cardiologist outpatient encounter within the last year, atstep 1134, it is determined if a referral agent was run for thehealthcare provider and patient combination in the past 30 days. If so,in step 1128, the process ends and no referral is made. If not, then instep 1136, a suggestion is provided to the healthcare provider for thereferral agent.

FIG. 12 depicts an algorithm 1200 for assigning a physician to one ormore patient in a heart failure registry. It should be understood thatthe specific steps and the order of the steps depicted in the algorithm1200 are only exemplary and that other steps and different orders of thesteps may be user. In addition, it should be understood that there otherpossible variations for the algorithm 1200 within the scope of thepresent invention.

At step 1202, data from one or more patients in a heart failure registryis received. At step 1218, for one or more patients classified as havingclass B, C, D heart failure or reduced EF, it is determined if such apatient has a cardiologist. If so, then at step 1220, the cardiologistis placed fixed at the top of the list and is designated as the “currentcardiologist.” After step 1220, or if it is determined in step 1218 thatthe patient does not have a cardiologist, at step 1222, the system isqueried for cardiologist providers. Then at step 1224, a primary sort ofa cardiologist provider list by payor compatibility is performed. Thenat step 1226 a secondary sort of the cardiologist provider list bylanguage compatibility is performed. Then at step 1228, a tertiary sortof the cardiologist provider list by location compatibility isperformed. Then at step 1230, for the patients having class B, C, Dheart failure or reduced EF, a list of cardiologist providers isgenerated for the best match.

In addition, at step 1204, for all the patients in the heart failureregistry, it is determined if the patient has a PCP and if so, the PCPis placed fixed at the top of the list and designated as the “currentPCP” in step 1206. Regardless of whether the patient has a PCP or not,at step 1208, the system is queried for PCP providers. At step 1210, aprimary sort of a PCP provider list by payor compatibility is performed.Then at step 1212 a secondary sort of the PCP provider list by languagecompatibility is performed. Then at step 1214, a tertiary sort of thePCP provider list by location compatibility is performed. Then at step1216, for all the patients in the heart failure registry, a list of PCPproviders is generated for the best match.

After steps 1216 and 1230, at step 1232, a notification is formatted tothe user and includes the top 10 providers. At step 1234, designationsfor PCPs and cardiologists are provided. Then at step 1236, appropriaterationale on a provider basis is provided. At step 1238, an option toview the next ten providers is provider, and at step 1240, the processends.

FIG. 13 depicts an algorithm 1300 that may be utilized to providetransition management care by facilitating the provision of additionalservices for a patient. It should be understood that the specific stepsand the order of the steps depicted in the algorithm 1300 are onlyexemplary and that other steps and different orders of the steps may beuser. In addition, it should be understood that there other possiblevariations for the algorithm 1300 within the scope of the presentinvention.

At step 1302, it is determined that other services, such as follow upsupport, education, etc., may be necessary for the patient. At step1304, it is determined if additional referrals are required for theadditional services, and if not, at step 1306 the process stops. Ifadditional referrals are required, it is determined if support groups,nutritional consultations, outpatient cardiac rehabilitation, physicalactivity access, and education services are needed at steps, 1308, 1310,1312, 1314, and 1316, respectively. If any of the services of steps1308, 1310, 1312, 1314, and 1316 are needed, at step 1318, it isdetermined if insurance will cover these services. If not, then at step1322, it is determined if there are free services available. If thereare no free services available, then at step 1324, as a last resort, thehealthcare provider is directed to educate the patient at that time, ifpossible. If insurance will cover the services or there are freeservices available, then at step 1320, a referral is sent. At step 1326,the healthcare provider is directed to educate the patient regarding thearranged services and verify that the patient has access to and anunderstanding of the services. At step 1328, a transportation workflowis initiated to facilitate transportation to the services, if necessary,and at step 1330 the process ends.

FIGS. 14-27 depict various aspects of a population health managementsystem, e.g., the population health management system 200. The aspectsof the population health management system depicted in FIGS. 14-27 aremerely exemplary and it should be understood that additional aspects orvariations on the aspects depicted in FIGS. 14-27 are within the scopeof the present invention.

FIG. 14 depicts an overview 1400 of a health system that can be providedto a healthcare provider 1410. The healthcare provider 1410 can be anyhealthcare provider associated with the health system, such as aphysician, physician's assistant, nurse, care manager, and/oradministrator. The overview 1400 can be displayed on one or moredevices, such as the devices 240 discussed above with reference to FIG.2. In one or more embodiments, the overview 1400 may be generated, atleast in part, by one or more components of a population health server,such as the population health server 250 discussed above with referenceto FIG. 2.

In certain embodiments, the overview 1400 can include a key performanceindicator module 1420. In such embodiments, the key performanceindicator module 1420 can include various indicators that representdifferent features of a health system, such as health system utilization1422, financial information 1424, healthcare quality of 1426,operational indicators 1428, health system access indicators 1430,and/or appropriateness of the healthcare 1432.

In one or more embodiments, the overview can include alerts 1440associated with the health system. In certain embodiments, the alerts1440 can include alerts for trends associated with a population ofpatients cared for by the health system. For example, as depicted inFIG. 14, the alerts 1440 can include information related to rate ofreadmissions, compliance issues, and/or rate or number of prescriptionsbeing filled for a specific group of patients. In the embodimentdepicted in FIG. 14, the healthcare provider 1410 has the option ofaddressing, dismissing, or snoozing one or more alerts 1440 from thisoverview 1400.

In certain embodiments, the overview 1400 can include patient populationinformation 1450. In such embodiments, the patient populationinformation 1450 may include general characterizations of the patientpopulation in the health system. For example, in one embodiment, thepatient population information 1450 can include the percentage of thepatient population present in various classifications, such as beingclassified as having chronic conditions.

In various embodiments, the overview 1400 can include demographicinformation 1460 on the patient population present within the healthsystem. In the same or alternative embodiments, the overview can includesatisfaction metrics 1470 associated with the satisfaction of patientsand/or employees of the health system.

In certain embodiments, the information associated with the overview1400 can include information organized in various tabs, such as the tabs1480. In such embodiments, the health care provider 1410 can viewinformation associated with the payers or provider groups. In the sameor alternative embodiments, the health care provider 1410 can viewinformation associated with medical conditions or various health systemprograms.

In various embodiments, the overview 1400 can also include additionaltabbed portions 1490 where the healthcare provider 1410 can viewinformation associated with one or more registries, scorecards,medications, or outreach.

FIG. 15 depicts a program view 1500 for a specific program associatedwith a health system. The program view 1500 may be displayed on one ormore devices, such as the devices 240 discussed above with reference toFIG. 2. In one or more embodiments, the overview 1500 may be generated,at least in part, by one or more components of a population healthserver, such as the population health server 250 discussed above withreference to FIG. 2.

In certain embodiments, the program view 1500 may be associated with aparticular program offered by the health system. For example, in theembodiment depicted in FIG. 15, the program view 1500 includes a view ofa diabetes program. In certain embodiments, a healthcare provider, e.g.,the healthcare provider 1510, can navigate to the program view 1500 viaa health system overview, such as the health system overview 1400 ofFIG. 14. In such embodiments, a healthcare provider can navigate to theprogram view 1500 by clicking on a link 1442 to address an alert in theoverview 1400 of FIG. 14.

Returning now to FIG. 15, in certain embodiments, the program view 1500can include all available information related to a population ofpatients being treated for diabetes within the health system. Forexample, in such embodiments, the program view 1500 can include a columnlisting indicators or measures associated with the population ofpatients being treated for diabetes, such as one or more of: keyperformance indicators 1520; quality measures 1530; prescriptioninformation 1540; consultations/appointments attendance information1550; and personal patient documentation 1560 (such as logging of dietand/or home glucose tests). In one or more embodiments, the program view1500 can provide a main program view area 1542 of one or more of theindicators or measures 1520, 1530, 1540, 1550, and 1560.

In the embodiment depicted in FIG. 15, the main program view area 1542provides information associated with the prescriptions filed measure1540 from the column listing. In embodiments, the main program view 1542may be formatted differently depending upon which indicators or measures1520, 1530, 1540, 1550, and/or 1560 the healthcare provider 1510 ishighlighting for display. As seen in the embodiment depicted in FIG. 15,a main program view area 1542 may display a map 1544 highlightingpharmacies and clinics. In such embodiments, the main program view area1542 can illustrate the percentage of prescriptions filled at each ofthe pharmacies and clinics on the map 1544. In one or more embodiments,the main program view area 1542 can include a list 1580 of various typesof entities to display on the map 1544.

FIG. 16 depicts a healthcare provider overview 1600 for a healthcareprovider, such as the healthcare provider 1610. In embodiments, thehealthcare provider 1610 can be any healthcare provider associated withthe health system, such as, a physician, physician's assistant, nurse,care manager, and/or administrator. The healthcare provider overview1600 may be displayed on one or more devices, such as the devices 240discussed above with reference to FIG. 2. In one or more embodiments,the healthcare provider overview 1600 may be generated, at least inpart, by one or more components of a population health server, such asthe population health server 250 discussed above with reference to FIG.2.

The healthcare provider overview 1600 can include any or all informationassociated with the healthcare provider 1610 for a particular healthsystem. In such embodiments, the healthcare provider overview 1600 caninclude more than one potential display area. For example, in theembodiment depicted in FIG. 16, the healthcare provider overview 1600can include the tabs 1660 to enable the healthcare provider 1610 to viewinformation associated with various categories, such as worklist,outreach, performance, and connections. In one or more embodiments, thehealthcare provider overview 1600 can include a home view option 1662 toview information from several categories at once. For example, incertain embodiments, the home view option 1662 of the healthcareprovider overview 1600 can include a communications area 1620, aschedule area 1630, a performance area 1640, and/or a worklist area1650. In the embodiment depicted in FIG. 16, the communications area1620 can include: an inbox area 1622 that can display at least arepresentation of incoming messages, e.g., emails; a notification area1624 that can display at least a portion of notifications relating tothe healthcare provider's duties, and/or an announcement area 1626 todisplay announcements relating to the healthcare provider or the healthsystem.

In one or more embodiments, the schedule area 1630 can includescheduling information associated with the healthcare provider's duties.For instance, the schedule area can include a daily schedule component1632 of patient appointments for the healthcare provider 1610. In thesame or alternative embodiments, the schedule area 1630 can include areminders component 1634 to display reminders set up by or set up forthe healthcare provider 1610.

In certain embodiments, the performance area 1640 can includeinformation regarding the performance of the healthcare provider 1610 asit relates to various metrics associated with the patients under thecare of the healthcare provider 1610. For example, in one or moreembodiments, the performance area 1640 can include information relatedto the high risk population of patients 1642 seen by the healthcareprovider 1610, the top 5 chronic conditions 1644 of the population ofpatients seen by the healthcare provider 1610, and/or the treatmenttrends 1646, e.g., out of network utilization, of the population ofpatients seen by the healthcare provider 1610.

In one or more embodiments, the worklist area 1650 may include alertsfor one or more worklists associated with the healthcare provider 1610.In one embodiment, the worklist area 1650 can include any alerts forwhich a population health management system, such as the populationhealth management system 200 of FIG. 2, has deemed relevant for thehealthcare provider 1610 to be aware of. For example, in certainembodiments, the worklist area 1650 can include alerts and/ornotifications for the healthcare provider 1610 to be aware of new peoplethat have been added to a registry or program, e.g., the alert 1652. Inthe same or alternative embodiments, other alerts can be provided in theworklist area 1650, such as alerts relating to the patients seen by thehealthcare provider 1610 that detail emergency room visits, hospitaldischarge, readmission risk, and/or home device alerts.

In certain embodiments, one or more of the areas 1620, 1630, 1640, and1650 can include items that comprise links that lead to more expandedviews or to another view. For example, in one or more embodiments, whenthe healthcare provider 1610 clicks and/or touches the registry/programsworklist (New Persons Qualify) tile 1652 in the worklist area 1650, anew view 1700 may be opened, which is depicted in FIG. 17.

In one or more embodiments, the view 1700 of FIG. 17 may be generated,at least in part, by one or more components of a population healthserver, such as the population health server 250 discussed above withreference to FIG. 2. In certain embodiments, a healthcare worker, e.g.,the healthcare worker 1710, may choose to highlight information relatedto one of the patients provided on the worklist new persons list 1720,such as the patient 1748. In such embodiments, upon choosing tohighlight a specific patient, a situational view 1730 may be provided.The situational view 1730 can include a patient information area 1738, avitals and measurements area 1732, an appointments list area 1734, acare plan area 1736, an alerts area 1740, a longitudinal record area1744, and/or a care team list 1746.

The patient information area 1738 may include background information onthe patient 1748, such as age, contact information, and health insuranceinformation. In certain embodiments, the vitals and measurements area1732 can include data including blood pressure readings, height, weight,temperature, and/or heart rate. In the one or more embodiments, theappointments area 1734 may include a list of upcoming and/or previousmedical appointments for the patient 1748. In one or more embodiments,the care plan information 1736 can include medication information, dietinformation, exercise information, medical condition education, and/orappointments, recommended by one or more healthcare providers.

In various embodiments, the alerts area 1740 can include alerts relatedto the patient 1748. In such embodiments, the alerts can include anyinformation that a healthcare provider, e.g., the healthcare provider1710, may find relevant for providing care to the patient, such as thatthe patient 1748 that has been newly added to a diabetes registry.

In certain embodiments, the longitudinal record area 1742 can include alist of any longitudinal records associated with one or more conditionsof the patient 1748. In such embodiments, the healthcare provider 1710can click and/or touch one or more of the listed longitudinal records todisplay the full longitudinal record. In the same or alternativeembodiments, the longitudinal record area 1742 may include a list ofmedications that the patient 1748 is currently taking or is prescribedto be taking. In one or more embodiments, this list of medications mayinclude medications that the patient is no longer taking. An exemplarylongitudinal record is depicted in FIG. 18.

In one or more embodiments, the care team list 1746 can include a listof all the care team members, such as physicians, specialists, caremanagers, etc., associated with the patient 1748. In certainembodiments, the care team list 1746 can include links to contacting anyor all of the individual care team members.

In the embodiment depicted in FIG. 18, the view 1800 is identical to theview 1700 discussed above with reference to FIG. 17 with the exceptionthat the view 1800 includes an overlaid longitudinal record 1810. Inembodiments, the longitudinal record 1810 may be associated with apatient, e.g., the patient 1748 of FIG. 17.

In certain embodiments, the longitudinal record 1810 may be presented inany form known to one skilled in the art. For example, in embodiments,the longitudinal record 1810 may be presented as a pop-up windowoverlaying another view, such as the view 1800. In one or moreembodiments, the longitudinal record 1810 may be generated, at least inpart, by one or more components of a population health server, such asthe population health server 250 discussed above with reference to FIG.2.

In certain embodiments, the longitudinal record 1810 can include atimeline view area 1820, a potential complications viewing area 1830, amedication list area 1840, and/or an education area 1850. Inembodiments, the timeline view area 1820 can include a timeline view1822 that provides all the medical information associated with apatient, e.g., the patient 1748, regarding at least one medicalcondition, and may include information across all providers and/oracross all venues.

In one or more embodiments, the healthcare provider 1860 may interactwith the timeline view 1822 to reveal all or a portion of the medicalinformation related to a medical condition for a specified time. In oneembodiment, the timeline view 1822 can allow a healthcare provider,e.g., the healthcare provider 1860, to view information related to allclinical visits and clinical results associated with a particularcondition, e.g., diabetes, since the patient was diagnosed with thecondition up until the present moment. For example, as can be seen inthe embodiment depicted in FIG. 18, medical information window 1824 isdisplayed, which specifically details a random blood glucose measurementassociated with Oct. 10, 2013 at 10:35 AM. In certain embodiments, thescale of the timeline view 1822 may be changed by a healthcare provider,e.g., the healthcare provider 1860, using the timeline scaling tool1826.

In one or more embodiments, the potential complications viewing area1830 can include a list of one or more potential complicationsassociated with the medical condition of interest, such as diabetes. Forexample, the potential complications viewing area 1830 displays thatthere is a 27% chance of congestive heart failure in the next 12 months.

In certain embodiments, the medication list area 1840 can include a listof all medications that a patient, e.g., the patient 1748, is currentlytaking or is prescribed to take for any medical condition. In variousembodiments, the medication list area 1840 may include a list of all themedications that a patient is currently taking or is prescribed to takethat are related to the medical condition of interest, e.g., diabetes.

In various embodiments, the education area 1850 can include a list ofeducation programs recommended by a healthcare provider, e.g., thehealthcare provider 1860, for a patient related to the medical conditionof interest. In the embodiment depicted in FIG. 18, the education areaincludes a list of the education programs recommended by a healthcareprovider and additionally can include information on whether or not sucheducation programs have been completed by the patient.

FIG. 19 depicts a schedule view 1900 for a healthcare provider 1910 inaccordance with one embodiment of the present invention. The scheduleview 1900 may include a patient appointment list 1920 for a specificday. In the same or alternative embodiments, the schedule view caninclude a column view 1930 that may include an abbreviated schedule forthe healthcare provider 1910.

In various embodiments, the schedule view 1900 can include informationthat has been generated, at least in part, by one or more components ofa population health server, such as the population health server 250discussed above with reference to FIG. 2.

In certain embodiments, any or all of the components in the appointmentlist 1920 and/or column view 1930 can include links to furtherinformation about the appoint or patient associated with theappointment. For example, in one or more embodiments, the healthcareprovider 1910 may click on an area associated with a particular patientappointment, such as the appointment for the patient 1922 to revealrelevant information about this patient, such as that depicted in thepatient information view 2000 of FIG. 20.

The patient information view 2000 depicted in FIG. 20 can include any orall of the relevant information related to a particular patient, such asthe patient 1922 described above with reference to FIG. 19. In variousembodiments, the patient information view 2000 can include informationthat has been generated, at least in part, by one or more components ofa population health server, such as the population health server 250discussed above with reference to FIG. 2.

In certain embodiments, the patient information view 2000 can include ageneral patient information area 2020, a main view area 2030, and anavigation area 2060. The patient information area 2020 may includegeneral patient information that may be relevant to the healthcareprovider 2010 when viewing medical problems associated with the patient,such as age, weight, and/or prescription allergies.

In certain embodiments, the navigation area 2060 may list variouscategories of information associated with the patient through which thehealthcare provider 2010 may interact to view additional patientinformation. In certain embodiments, the additional patient informationmay be populated in the main view area 2030 and/or may appear as apop-up window on top of the patient information view 2000.

In one or more embodiments, the main view area 2030 may include aproblems area 2040 and a quality measures area 2050. In suchembodiments, the problems area 2040 may include a list of active 2070and historical 2080 problems for the patient, such as the activediabetes problem 2072 for the patient. Further, in such embodiments, thehealthcare provider 2010 may click on and/or touch any or all of theactive 2070 and/or the historical 2080 problems listed in the problemsarea 2040 to view additional information associated with that problem.For example, in one or more embodiments, when the healthcare provider2010 clicks on and/or touches the diabetes problem 2072, a pop-upcondition view may appear, such as that depicted in FIG. 21.

As can be seen in the embodiment depicted in FIG. 21, a pop-up conditionview 2110 can display over a patient information view 2100. In theembodiment depicted in FIG. 21, the patient information view 2100 ofFIG. 21 is substantially identical to the patient information view 2000described above with reference to FIG. 20 except for the presence of thepop-up condition view 2110. In certain embodiments, the pop-up conditionview 2110 can include a longitudinal record 2120 associated with aparticular medical condition, e.g., a diabetes condition. In suchembodiments, the longitudinal record 2120 may include all the propertiesand components as the longitudinal record 1810 discussed above withreference to FIG. 18. For example, in such embodiments, the longitudinalrecord 2120 may include a timeline view area 2130, a potentialcomplications viewing area 2140, a medication list area 2150, and/or aneducation area 2160.

FIG. 22 depicts a patient workflow interface 2200 for a healthcareprovider, e.g., the healthcare provider 2210. The patient workflowinterface 2200 can include a patient information area 2220, a main area2230, and a navigation area 2260. The patient information area 2220 mayinclude pertinent patient information for a healthcare provider 2210 forrecommending care to the patient, such as age, weight, and/orprescription allergies.

In certain embodiments, the navigation area 2260 can include a list ofcategories of information associated with the patient from which thehealthcare provider 2210 may interact with to view additionalinformation or take additional actions.

In one or more embodiments, the main area 2230 can include additionalinformation related to one or more of the categories from the navigationarea 2260 chosen by the healthcare provider 2210. In the embodimentdepicted in FIG. 22, the main area 2230 can include a care planrecommendation interface 2240 and a patient education interface 2250. Incertain embodiments, the care plan recommendation interface 2240 can beconfigured to provide care recommendations for one or more medialconditions. In such embodiments, the healthcare provider 2210 can havethe option to add and/or remove care recommendations for the one or moremedical conditions. In various embodiments, the patient educationinterface 2250 can be configured to allow a healthcare provider 2210 tosearch a patient education database and/or select patient educationprograms recommended for the patient.

FIG. 23 depicts a patient management interface 2300 for a healthcareprovider, e.g., the healthcare provider 2310. In embodiments, thepatient management interface 2300 can provide at least a portion ofpatient information associated with the patients that are under the careof the healthcare provider 2310. In one or more embodiments, the patientmanagement interface 2300 may be generated, at least in part, by one ormore components of a population health server, such as the populationhealth server 250 discussed above with reference to FIG. 2.

In certain embodiments, the patient management interface 2300 can beconfigured to organize at least a portion of the patient informationassociated with the healthcare provider 2310 into multiple formats. Forexample, the patient management interface 2300 can include viewing taboptions 2320 for the healthcare provider 2310 to choose when viewing thepatient information. In the embodiment depicted in FIG. 23, thedashboard viewing option 2322 is selected. In the dashboard view, thepatient management interface 2300, in certain embodiments, can include apatient population area 2330, a communications area 2340, and acategorical snapshot area 2360.

In certain embodiments, the patient population area 2330 can provide oneor more metrics associated with the population of patients under thecare of the healthcare provider 2310. For example, in the embodimentdepicted in FIG. 23, the patient population area 2330 can includeinformation related to the proportion of patients 2332 that are highrisk, which may be presented in a graphical format. In the same oralternative embodiments, the patient population area 2330 can include alist 2334 of the top five chronic conditions among the population ofpatients under the care of the healthcare provider 2310 and/or a list ofthe persons or patients of interest 2336.

In one or more embodiments, the communications area 2340 can include alist of announcements 2342 and/or notifications 2344 for the healthcareprovider 2310 in relation to the population of patients and/or inrelation to the health system associated with the healthcare provider2310.

In various embodiments, the categorical snapshot area 2360 may includetiles, e.g., the tiles 2362, 2364, and 2366, which can each provide abrief overview of the patient information organized in the variouscategories associated with the viewing tab options 2320. For example, inembodiments, the tile 2366 may include a brief overview of selectinformation relating to medications.

FIG. 24 depicts a patient management interface 2400 for a particularhealthcare provider, e.g., the healthcare provider 2410. In embodiments,the patient management interface 2400 can provide at least a portion ofpatient information associated with the patients that are under the careof the healthcare provider 2410. In one or more embodiments, the patientmanagement interface 2400 may be generated, at least in part, by one ormore components of a population health server, such as the populationhealth server 250 discussed above with reference to FIG. 2.

In certain embodiments, the patient management interface 2400 can beconfigured to organize at least a portion of the patient informationassociated with the healthcare provider 2410 in multiple formats. Forexample, the patient management interface 2400 can include viewing taboptions 2420 for the healthcare provider 2410 to choose when viewing thepatient information. In the embodiment depicted in FIG. 24, theregistries viewing option 2422 is selected. In the registries viewingoption 2422, the patient management interface 2400, in certainembodiments, can include a registry information interface 2430.

The registry information interface 2430 may include a depiction ofvarious metrics for at least a portion of the registries associated withthe population patients under the care of the healthcare provider 2410.For example, in the embodiment depicted in FIG. 24, the registryinformation interface 2430 can include a plurality of tiles 2438 whichcan depict what percentage of patients have received care associatedwith that registry. For example, as depicted in the tile 2439, 21% ofthe patients have received care related to their presence in thediabetes registry.

In certain embodiments, the registry information interface 2430 can beconfigured to provide the healthcare provider 2410 various viewingoptions for the registries. For instance, in such embodiments, theregistry information interface 2430 can include a viewing option 2434for viewing all registries or a specific registry. In the same oralternative embodiments, the registry information interface 2430 caninclude a viewing option 2432 for viewing specific information about theregistries that are chosen for viewing, such as a quality score. In oneembodiment, a quality score can depict the percentage of patients thathave received care or a consultation with respect the conditionassociated with a particular registry and/or the percentage of patientsthat have received care or a consultation with respect a particulartreatment associated with a particular population of patients in aparticular registry.

In one or more embodiments, the patient management interface 2400 caninclude near real-time data that is supplied from a population healthmanagement system, such as the population health management system 200discussed above with respect to FIG. 2. In such embodiments, the patientmanagement interface 2400 may include an update indicator 2440 so thatthe healthcare provider 2410 can be aware how current the informationis. As used herein, near real-time data can mean data that is availablefor viewing or processing by one or more components of a populationhealth management system, such as the population health managementsystem 200 discussed above with respect to FIG. 2, within at least about1 minute, 10 minutes, 30 minutes, 60 minutes, 120 minutes, 240 minutes,or 480 minutes of being input into any component or portion of such apopulation health management system.

FIG. 25 depicts a patient management interface 2500 for a particularhealthcare provider, e.g., the healthcare provider 2510. In embodiments,the patient management interface 2500 can provide at least a portion ofpatient information associated with the patients that are under the careof the healthcare provider 2510. In one or more embodiments, the patientmanagement interface 2500 may be generated, at least in part, by one ormore components of a population health server, such as the populationhealth server 250 discussed above with reference to FIG. 2.

In certain embodiments, the patient management interface 2500 canorganize at least a portion of the patient information associated withthe healthcare provider 2510 in multiple formats. Further, in suchembodiments, the patient management interface 2500 can include viewingtab options 2520 for the healthcare provider 2510 to choose when viewingthe patient information. In the embodiment depicted in FIG. 25, theregistries viewing option 2522 is selected. In the registries viewingoption 2522, the patient management interface 2500, in certainembodiments, can include a registry information interface 2530.

Like the registry information interface 2430 discussed above withreference to FIG. 24, the registry information interface 2530 canprovide the healthcare provider 2510 various viewing options for theregistries. For instance, the registry information interface 2530 mayinclude a viewing option 2532 for viewing all registries or a specificregistry and/or a viewing option 2534 for viewing specific informationabout the registries that are chosen for viewing, such as a qualityscore. In the embodiment depicted in FIG. 25, the specific registry ofdiabetes care and the associated quality score were selected.

Further, like the registry information interface 2430 of FIG. 24, theregistry information interface 2530 may include a depiction of variousmetrics for at least a portion of the population of patients in thediabetes care registry that are under the care of the healthcareprovider 2510. For example, in the embodiment depicted in FIG. 25, theregistry information interface 2530 can include a plurality of tiles2536 which can depict what percentage of patients have received care forvarious treatment aspects associated with diabetes care. For example, asdepicted in the tile 2538, 12% of these patients have received a footexam.

The patient management interface 2600 depicted in FIG. 26 is similar tothe patient management interface 2500 discussed above with respect toFIG. 25, with the exception that the program measures viewing option2614 was selected along with the diabetes care registry 2612 to populatethe registry information interface 2610.

In the embodiment depicted in FIG. 26, the registry informationinterface can include a list 2620 of various program measures and mayfurther include a graphical representation of the compliance levelassociated with those measures. For instance, as seen in the embodimentdepicted in FIG. 26, the list 2620 can include personal patientdocumentation measure indicators 2622, healthcare event compliancemeasure indicators 2624, and/or diabetes program compliance measureindicators 2626.

FIG. 27 depicts a patient interface 2700 where a patient, e.g., thepatient 2710, may view and interact with information associated with anyor all care programs associated with the patient's various medicalconditions. In certain embodiments, the patient interface 2700 mayinclude a list 2720 of associated healthcare providers, a navigationpanel 2730, a main view area 2740, and a communication interface area2760.

In certain embodiments, the navigation panel 2730 may include a list ofvarious categories of information of which the patient 2710 may chooseto view in the main view area 2740 and/or to open new windows foradditional information associated with a particular category.

In the embodiment depicted in FIG. 27, the main view area 2740 caninclude a plan view area 2770, which may display various aspects of oneor more care plans assigned to the patient 2710, such as medication,diet, and/or appointments. In the same or alternative embodiments, themain view area 2740 can include a recent results area 2750 that candisplay one or more results or data from a medical device, such as aweight scale or a blood pressure monitor.

In one or more embodiments, the communication interface area 2760 may beconfigured to allow the patient to contact or engage a number of variousgroups. For example, in such embodiments, the communication interface2760 may include links so that the patient 2710 can contact or messageone or more healthcare providers, contact or message a particularcommunity of patients, pay a medical bill, or obtain additional wellnessinformation.

FIG. 28 depicts an exemplary flow diagram for a method 2800 thatfacilitates designing and utilizing population health programs.Initially, at step, 2810 healthcare data from disparate sources can bereceived by a population health server. In one embodiments, the step2810 may be performed at least partly by the receiving component 252discussed above with reference to FIG. 2. In embodiments, the healthcaredata may include any or all of the properties of the healthcare datadiscussed above with reference to the EMRs 212 of FIG. 2. In step 2812,the population health server can be utilized to identify a population ofpatients based on a set of criteria. In certain embodiments, the step2812 may be performed at least partly by the identifying component 254discussed above with reference to FIG. 2. In step 2814, the populationhealth server can utilized to stratify the population of patients basedon one or more algorithms to create one or more groups of patients. Incertain embodiments, the step 2814 may be at least partly performed bythe stratifying component 256 discussed above with reference to FIG. 2.In step 2816, the population health server can be utilized to create atleast one registry, the at least one registry comprising at least aportion of the one or more groups. In one embodiment, the step 2816 maybe performed at least partly by the creating component 258 discussedabove with reference to FIG. 2. In one embodiment, the population healthserver of steps 2810, 2812, 2814, and/or 2816 can have any or all of theproperties of the population health server 250 discussed above withreference to FIG. 2.

FIG. 29 depicts an exemplary flow diagram for a method 2900 thatfacilitates designing and utilizing population health programs. In step2910, healthcare data from disparate sources can be received by apopulation health server. In one embodiments, the step 2910 may beperformed at least partly by the receiving component 252 discussed abovewith reference to FIG. 2. In embodiments, the healthcare data mayinclude any or all of the properties of the healthcare data discussedabove with reference to the EMRs 212 of FIG. 2. In step 2912, thepopulation health server can be utilized to identify a population ofpatients based on one or more medical conditions. In certainembodiments, the step 2912 may be performed at least partly by theidentifying component 254 discussed above with reference to FIG. 2. Instep 2914, the population health server can be utilized to stratify thepopulation of patients into one or more groups based on at least onealgorithm. In certain embodiments, the step 2914 may be at least partlyperformed by the stratifying component 256 discussed above withreference to FIG. 2. In step 2916, an opportunity for a clinician toconfirm an output of the at least one algorithm can be provided. In oneembodiment, the step 2916 may be performed at least partly by the outputcomponent 260 discussed above with reference to FIG. 2. In step 2918,the population health server can be utilized to create at least oneregistry for the population of patients based on at least a portion ofthe output of the at least one algorithm. In one embodiment, thepopulation health server of steps 2910, 2912, 2914, and/or 2918 can haveany or all of the properties of the population health server 250discussed above with reference to FIG. 2.

FIG. 30 depicts an exemplary flow diagram for a method 3000 forstratifying one or more patients into one or more groups. In step 3010,healthcare data can be received by a population health server. Thehealthcare data may include clinical impressions and/or clinicalnarratives from one or more healthcare providers. In embodiments, thehealthcare data may include any or all of the properties of thehealthcare data discussed above with reference to the EMRs 212 of FIG.2. In one embodiment, the step 3010 may be performed at least partly bythe receiving component 252 discussed above with reference to FIG. 2. Instep 3012, the population health server can be utilized for naturallanguage processing to extract one or more clinical indicators from thehealthcare data. In certain embodiments, the step 3012 may be at leastpartly performed by the natural language processing component 270discussed above with reference to FIG. 2. In step 3014, the populationhealth server can be utilized to stratify one or more patients into oneor more groups based on at least a portion of the one or more clinicalindicators. In one embodiments, the step 3014 may be at least partlyperformed by the stratifying component 256 discussed above withreference to FIG. 2. In step 3016, the population health server can beutilized to create at least one registry comprising the one or moregroups. The at least one registry may account for one or more of:resources available to a patient; lifestyle and prognostic assets thatcan be used for prediction; and assets necessary for attribution,allocation, or measurement. In certain embodiments, the step 3016 may beat least partly performed by the creating component 258 discussed abovewith reference to FIG. 2. In one embodiment, the population healthserver of steps 3010, 3012, 3014, and/or 3016 can have any or all of theproperties of the population health server 250 discussed above withreference to FIG. 2.

FIG. 31 depicts an exemplary flow diagram for a method 3100 forstratifying one or more patients into one or more groups. In step 3110,healthcare data from disparate sources can be received by a populationhealth server. The healthcare data may comprise clinical impressionsand/or clinical narratives from one or more healthcare providers. In oneembodiment, the step 3110 may be performed at least partly by thereceiving component 252 discussed above with reference to FIG. 2. Inembodiments, the healthcare data may include any or all of theproperties of the healthcare data discussed above with reference to theEMRs 212 of FIG. 2. In step 3112, the population health server can beutilized for natural language processing to extract one or more clinicalindicators from the healthcare data, where the one or more clinicalindicators are associated with one or more chronic conditions. Incertain embodiments, the step 3112 may be at least partly performed bythe natural language processing component 270 discussed above withreference to FIG. 2. In step 3114, a relevance rating can be provided toeach of the one or more clinical indicators. In one embodiments, thestep 3114 may be at least partly performed by the natural languageprocessing component 270 discussed above with reference to FIG. 2. Instep 3116, the population health server can be utilized to stratify oneor more patients into one or more groups based on at least a portion ofthe one or more clinical indicators. In one embodiment, the step 3116may be at least partly performed by the stratifying component 256discussed above with reference to FIG. 2. In step 3118, the populationhealth server can be utilized to create at least one registry comprisingthe one or more groups. The at least one registry may account for one ormore of: resources available to a patient; lifestyle and prognosticassets that can be used for prediction; and assets necessary forattribution, allocation, or measurement. In certain embodiments, thestep 3118 may be at least partly performed by the creating component 258discussed above with reference to FIG. 2. In one embodiment, thepopulation health server of steps 3110, 3112, 3116, and/or 3118 can haveany or all of the properties of the population health server 250discussed above with reference to FIG. 2.

FIG. 32 depicts an exemplary flow diagram for a method 3200 thatfacilitates using at least one clinically relevant algorithm inpopulation health programs. In step 3210, healthcare data from disparatesources can be received by a population health server. In oneembodiment, the step 3210 may be performed at least partly by thereceiving component 252 discussed above with reference to FIG. 2. Inembodiments, the healthcare data may include any or all of theproperties of the healthcare data discussed above with reference to theEMRs 212 of FIG. 2. In step 3212, the population health server can beutilized to stratify a population of patients based on one or morealgorithms to create one or more groups of patients, where the one ormore algorithms comprise at least one clinically relevant algorithmutilizing clinical data. In one or more embodiments, the clinical datacan have any or all of the properties of the clinical data discussedabove with reference to the EMRs 212 of FIG. 2. In certain embodiments,the step 3212 may be performed at least partly by the stratifyingcomponent 256 discussed above with reference to FIG. 2. In step 3214,the population health server can be utilized to create at least oneregistry, the at least one registry comprising at least a portion of theone or more groups. In one embodiment, the step 3214 may be at leastpartly performed by the creating component 258 discussed above withreference to FIG. 2. In one embodiment, the population health server ofsteps 3210, 3212, and/or 3214 can have any or all of the properties ofthe population health server 250 discussed above with reference to FIG.2.

FIG. 33 depicts an exemplary flow diagram for a method 3300 thatfacilitates utilizing clinically relevant algorithms for registrypopulation. In step 3310, healthcare data from disparate sources can bereceived by a population health server. In one embodiment, the step 3310may be performed at least partly by the receiving component 252discussed above with reference to FIG. 2. In embodiments, the healthcaredata may include any or all of the properties of the healthcare datadiscussed above with reference to the EMRs 212 of FIG. 2. In step 3312,the population health server can be utilized to identify a population ofpatients based, at least partly, on one or more medical conditions. Inone embodiment, the step 3312 may be at least partly performed by theidentifying component 254 discussed above with reference to FIG. 2. Instep 3314, the population health server can be utilized to stratify thepopulation of patients based on at least a clinically relevantalgorithm, the clinically relevant algorithm utilizing clinical data.The clinical data including one or more of medication information,laboratory values, diagnostics, clinician narratives, and clinicianassessments. In one or more embodiments, the clinical data can have anyor all of the properties of the clinical data discussed above withreference to the EMRs 212 of FIG. 2. In certain embodiments, the step3314 may be performed at least partly by the stratifying component 256discussed above with reference to FIG. 2. In step 3316, the populationhealth server can be utilized to create at least one registry for thepopulation of patients based on at least a portion of an output of theclinically relevant algorithm. In one embodiment, the step 3316 may beat least partly performed by the creating component 258 discussed abovewith reference to FIG. 2. In step 3318, the population health server canbe utilized to update the at least one registry when additional clinicaldata is available for the clinically relevant algorithm to utilize. Inone embodiment, the step 3318 is at least partly performed by thereceiving component 252, the stratifying component 256, and/or thecreating component 258 discussed above with reference to FIG. 2. In oneembodiment, the population health server of steps 3310, 3312, 3314,3316, and/or 3318 can have any or all of the properties of thepopulation health server 250 discussed above with reference to FIG. 2.

Referring now to FIG. 34, an exemplary flow diagram is depicted of amethod 3400 of providing a cross venue antibiogram. Initially, at step3410, medications information is received from disparate sources. Thedisparate sources may include multiple venues, multiple providers, andacross multiple conditions (e.g., from more than one registryidentifying more than one condition). Susceptibility results based ontesting associated with patient information are received, at step 3412,from the disparate sources. The susceptibility results may includeresults from testing being performed on inpatients, outpatients, andpatients within the community outside of a hospital setting (e.g.,non-acute care settings). The susceptibility results may include patientdemographics but does not include patient identifiers.

A cross venue antibiogram is created, at step 3414, based on themedications information and the susceptibility results. At step 3416,the cross venue antibiogram is communicated to a clinician device. Thecross venue antibiogram allows the clinician to more accuratelyprescribe medications by providing information as to which medicationswill be most effective based on the patients circumstances and locationor setting and provides a broad view of susceptibility result trends. Inembodiments, one or more populations can be monitored, based on thecross venue antibiogram, for development of antimicrobial resistance,unnecessary prescriptions, incorrect or more costly medications,neglecting to order follow up labs to monitor for adverse drugreactions, patients not refilling medications as prescribed, druginteractions for patients using multiple pharmacies and/or providers.

In one embodiment, filtering of the antibiogram is enabled based onselected demographics. In this regard, a clinician can filter theantibiogram based on circumstances relevant to the patient to create apatient-specific antibiogram. The demographics may include aninstitution, a practice associated with a clinician, a zip code, acounty, a city, a state, a region, or a country. A specific diseasestate may be selected for a patient or received from one or more datasources. Patient information including related conditions, laboratoryresults, and allergy information for the patient may additionally bereceived from one or more data sources. Multiple medication options forthe patient may be provided based on the received information and thepatient-specific antibiogram. The medication options may include dosing,generic alternatives, cost, availability, and susceptibilityinformation, the cost including relative cost, actual wholesale price,institution cost, patient cost, or cost effectiveness, and/or theavailability including a numerical amount or relative amount of a drugin stock.

In embodiments, the cross venue antibiogram can be further utilized todetermine a medication for a patient is being prescribed appropriately,as shown at step 3418. For example, information from a data source mayindicate the patient was prescribed a medication that is ineffectivegiven the patient's condition or particular location. Similarly, theinformation may indicate a different medication is more effective. Inthese examples, it is determined that the medication is not beingprescribed appropriately. In a situation where the information indicatesthe medication is the most effective given the patient's condition orparticular location, it is determined that the mediation is beingprescribed appropriately. In an embodiment, if it is determined that themedication is not being prescribed appropriately, inappropriate trends(i.e., the medication is not being prescribed appropriately) may beflagged at step 3420. Additionally or alternatively, a medicationsteward may be alerted to intervene. Inappropriate trends and/orinterventions may be documented via an automated messaging system.Similarly, in one embodiment, interventions may be electronicallycaptured for trending and reporting. Provider prescribing trends andeffects of intervention may be monitored, at step 3422.

In embodiments, information from a data source may indicate the patientwas prescribed a medication that requires a particular form ofmonitoring, follow-up, education, additional laboratories, and the like.Based on additional information from a data source that may indicate arequirement has or has not been fulfilled, in one embodiment, it isassessed, at step 3424, if the patient is being properly monitored andeducated. In one embodiment, as shown at step 3426, patient or cliniciannon-compliance and the need for additional education is predicted. Inone embodiment, any or all of the steps of method 2400 may be at leastpartly performed by one of various components of the population healthserver 250 discussed above with reference to FIG. 2.

Turning now to FIG. 35, an exemplary flow diagram is depicted of amethod 3500 of providing a comprehensive medication advisor. Initially,at step 3510, a selection of a disease state is received from aclinician device. Patient information including related conditions,laboratory results, allergy information for the patient is received fromone or more electronic medical records at step 3512. Utilizingsusceptibility data, based on a cross venue antibiogram, one or moremedication options are provided for the disease state, at step 3514. Themedication options may include dosing, generic alternatives, cost,availability, and susceptibility information. The cost may includerelative cost, actual wholesale price, institution cost, patient cost,or cost effectiveness. The availability may include a numerical amountor relative amount of a drug in stock. The susceptibility informationmay be based on the antibiogram and may include information relevant toone or more of the patient, an institution, a practice associated with aclinician, a zip code, a county, a city, a state, a region, or acountry. The one or more medication options are provided to theclinician device, at step 3516. In one embodiment, as shown at step3518, if a clinician prescribes a medication that is not one of the oneor more medication options, a medication steward is alerted tointervene. Alternatively or additionally, prescribing trends and effectsof intervention is monitored, in one embodiment, at step 3520. In oneembodiment, any or all of the steps of method 3500 may be at leastpartly performed by one of various components of the population healthserver 250 discussed above with reference to FIG. 2.

The present invention has been described in relation to particularembodiments, which are intended in all respects to be illustrativerather than restrictive. Further, the present invention is not limitedto these embodiments, but variations and modifications may be madewithout departing from the scope of the present invention.

What is claimed is:
 1. One or more computer storage media storingcomputer-executable instructions that, when executed by one or morecomputing devices, cause the one or more computing devices to perform amethod for providing medication stewardship, the method comprising:receiving medications information from disparate sources includinginformation from multiple venues, multiple providers, and acrossmultiple conditions; based at least in part on the medicationsinformation, providing to a clinician via a clinician device multiplemedication options for one or more patients, the medication optionsincluding dosing, generic alternatives, cost, availability, and/orsusceptibility information; and flagging inappropriate trends and/oralerting a medication steward to intervene.
 2. The media of claim 1further comprising receiving susceptibility results based on testingassociated with patient information from the disparate sources.
 3. Themedia of claim 2, further comprising creating a cross venue antibiogrambased on the medications information and the susceptibility results. 4.The media of claim 1, wherein the cost includes relative cost, actualwholesale price, institution cost, patient cost, or cost effectiveness,the availability including a numerical amount or relative amount of adrug in stock, the susceptibility information based on a cross venueantibiogram.
 5. The claim 1, further comprising providing directfeedback, via the clinician device, to the clinician if a particular useof a medication is deemed inappropriate.
 6. The media of claim 1,wherein the medication options for a particular patient is based on atleast in part on specific clinical data relevant to the particularpatient.
 7. The media of claim 1, further comprising identifyingemerging trends in treatment failure or ineffectiveness.
 8. The media ofclaim 1, further comprising monitoring patient adherence or lack thereofin association with one of the medication options.
 9. The media of claim1, further comprising detecting drug-drug interactions for patients whouse multiple pharmacies in association with the medication options. 10.The media of claim 1, further comprising assessing if the one or morepatients are being properly monitored and educated in association withone of the medication options.
 11. The media of claim 1, furthercomprising predicting patient or clinician non-compliance in associationwith one of the medication options.
 12. The media of claim 1, furthercomprising predicting the need for additional education in associationwith one of the medication options.
 13. The media of claim 1, furthercomprising documenting interventions via an automated messaging system.14. The media of claim 13, further comprising documenting outcomes ofthe interventions via the automated messaging or manually by aclinician.
 15. The media of claim 1, wherein the inappropriate trendsinclude deviation from one of the medication options, development ofantimicrobial resistance, unnecessary prescriptions, incorrect or morecostly medications, neglecting to order follow up laboratories tomonitor for adverse drug reactions, patients not refilling medicationsas prescribed, and/or drug interactions from patients using multiplepharmacies and/or providers.
 16. The media of claim 1, wherein themedication options include antihypertensives, antihyperlipidemics,anlagesics, and anticoagulants.
 17. A computer-implemented methodcomprising: receiving medications information from disparate sourcesincluding information from multiple venues, multiple providers, andacross multiple conditions; based at least in part on the medicationsinformation, providing to a clinician via a clinician device multiplemedication options for one or more patients, the medication optionsincluding dosing, generic alternatives, cost, availability, and/orsusceptibility information; and flagging inappropriate trends and/oralerting a medication steward to intervene, wherein the inappropriatetrends include deviation from one of the medication options, developmentof antimicrobial resistance, unnecessary prescriptions, incorrect ormore costly medications, neglecting to order follow up laboratories tomonitor for adverse drug reactions, patients not refilling medicationsas prescribed, and/or drug interactions from patients using multiplepharmacies and/or providers.
 18. The method of claim 17, furthercomprising providing direct feedback, via the clinician device, to theclinician if a particular use of a medication is deemed inappropriate.19. The method of claim 17, wherein the medication options for aparticular patient is based on at least in part on specific clinicaldata relevant to the particular patient.
 20. A computerized systemcomprising: one or more processors; and one or more computer storagemedia storing computer-useable instructions that, when used by the oneor more processors, cause the one or more processors to: receivemedications information from disparate sources including informationfrom multiple venues, multiple providers, and across multipleconditions; based at least in part on the medications information,provide to a clinician via a clinician device multiple medicationoptions for one or more patients, the medication options includingdosing, generic alternatives, cost, availability, and/or susceptibilityinformation; and flag inappropriate trends and/or alerting a medicationsteward to intervene, the inappropriate trends including deviation fromone of the medication options, development of antimicrobial resistance,unnecessary prescriptions, incorrect or more costly medications,neglecting to order follow up laboratories to monitor for adverse drugreactions, patients not refilling medications as prescribed, and/or druginteractions from patients using multiple pharmacies and/or providers.